Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 04 Feb 2005 15:43:35 -0600
From:      Guy Helmer <ghelmer@palisadesys.com>
To:        Ruslan Ermilov <ru@FreeBSD.org>
Cc:        freebsd-net@FreeBSD.org
Subject:   Re: Netgraph performance question
Message-ID:  <4203EC87.3070504@palisadesys.com>
In-Reply-To: <20050204204804.GC71363@ip.net.ua>
References:  <4203AAE3.4090906@palisadesys.com> <20050204204804.GC71363@ip.net.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
Ruslan Ermilov wrote:

>Hi Guy,
>
>On Fri, Feb 04, 2005 at 11:03:31AM -0600, Guy Helmer wrote:
>  
>
>>A while back, Maxim Konovalov made a commit to usr.sbin/ngctl/main.c to 
>>increase its socket receive buffer size to help 'ngctl list' deal with a 
>>big number of nodes, and Ruslan Ermilov responded that setting sysctls 
>>net.graph.recvspace=200000 and net.graph.maxdgram=200000 was a good idea 
>>on a system with a large number of nodes.
>>
>>I'm getting what I consider to be sub-par performance under FreeBSD 5.3 
>>from a userland program using ngsockets connected into ng_tee to play 
>>with packets that are traversing a ng_bridge, and I finally have an 
>>opportunity to look into this.  I say "sub-par" because when we've 
>>tested this configuration using three 2.8GHz Xeon machines with Gigabit 
>>Ethernet interfaces at 1000Mbps full-duplex, we obtained peak 
>>performance of a single TCP stream of about 12MB/sec through the 
>>bridging machine as measured by NetPIPE and netperf.
>>
>The bottleneck must be in ng_tee(4) -- the latter uses m_dup(9) when
>a duplicate is needed, which is very expensive as it has to create a
>writable copy of the entire mbuf chain (the original chain is DMA'ed
>into the host memory by the network card).
>  
>
I'm sorry, I mis-wrote.  My ng_tee is actually modified to only passes 
packets to the r2l/l2r hooks if they are connected, otherwise packets 
are passed directly to the left/right hooks (so it's an optional 
divert),  so there is no m_dup anymore in my modified ng_tee.

>>I'm wondering if bumping the recvspace should help, if changing the 
>>ngsocket hook to queue incoming data should help, if it would be best to 
>>replace ngsocket with a memory-mapped interface, or if anyone has any 
>>other ideas that would help performance.
>>
>If you absolutely need to see *all* GigE traffic in userland, then
>it's going to be troublesome.  If not, filter it with ng_bpf(4).
>  
>
Thanks, Ruslan.  Yes, I do need to pass all the traffic down through my 
userland daemon.  Since I'm just beginning to work with Netgraph, I was 
wondering if there was something simple or obvious that I was missing, 
or if there was a known performance issue with one of the nodes I'm 
using (as you pointed out with ng_tee).

I assumed that the bridging and trip through userland would only add 
latency to the connection, but the result of the performance test seemed 
to indicate that there is either a bottleneck I need to solve or my 
testing methodology was flawed.

Thanks again,
Guy



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4203EC87.3070504>