Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 31 Aug 2004 18:02:18 -0600
From:      Scott Long <scottl@samsco.org>
To:        Julian Elischer <julian@elischer.org>
Cc:        freebsd-arch@freebsd.org
Subject:   Re: option directive and turning on AOE
Message-ID:  <4135118A.5030807@samsco.org>
In-Reply-To: <4135051E.2070007@elischer.org>
References:  <Pine.LNX.4.60.0408311611550.7530@athena> <4134DF35.7070605@freebsd.org> <20040831203929.GB25134@odin.ac.hmc.edu> <4134E4B6.2030409@elischer.org> <4134FCAE.7374599A@freebsd.org> <4134FF74.4010105@freebsd.org> <4135051E.2070007@elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote:
> 
> 
> Scott Long wrote:
> 
>> Andre Oppermann wrote:
>>
>>>
>>
>> Having a single common interface is definitely attractive, but there are
>> performance and locking issues with the Netgraph framework that should
>> probably be resolved first. 
> 
> 
> both of these issues are in fact not major..
> netgraph itself has no locking issuess.. (Netgraph is the framework),
> but some of teh node types have issues.  Specifically, node types that 
> can be caled
> from outside the netgraph framework, such as nodes that tie netgraph to 
> other subsystems
> need to be worked on so that control enterring netgraph code from those 
> subsystems
> gets an appropriate lock. This is not always needed, but every node 
> needs to be
> examined with this in mind now that we have locking in teh rest of the 
> system
> more worked out.
> 
> performace..  well it can be fast. it depends on a lot of issues however..
> in particular how many locks get contentions.
> 
>>
>>
>> Scott
> 
> 
> 

My employer has done extensive profiling of packet delivery through
netgraph.  While the locking of the netgraph framework is definitely
correct, it's not terribly efficient and leads to a good deal of
latency.  We are looking at various proposals on how to address this.
This isn't a criticism of you or Netgraph, just a set 'real-life'
observations under very high load (bridging and packet inspection on
4 GigE links simultaneously qualifies as high load =-)

Scott



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4135118A.5030807>