Thanks for responding my email.
> 
> This is not the preferred solution, and definitely
> not meant to last forever.  For example, in 2.5.x
this needs to change
> and all netfilter modules are required to deal with
nonlinear skb's.
> 
> Regarding to your patch:  The main disadvantage is:
> It breaks the current
> netfilter hook API.  We always have to remember that
> we (i.e. the netfilter
> project with conntrack, nat, packet filtering, ...)
> are not the only user
> of this API and thus should not change an API during
> a stable kernel release.

Yeah, that is the flip side of the patch, but is there
anyother way we can 
inform nf_iterate routine to avoid linearizing skbs?
But I believe it is
netfilter hook which needs to tell what kind of skbs
it requires. 
Or take the responsibility of linearizing non-linear
skbs as you suggested.

Linearizing skbs in netfilter code is a big jolt on
the non-linear skb code path, 
which is inverting very effort of avoiding the copy
even though such packets does
not requires any conntracking, nating, or, pkt
filtering. 


> 
> Why do you need this patch ?  Which netfilter-using
> module doesn't need
> linear skb's?  Are there any free software projects
> using netfilter hooks
> who can deal with nonlinear skbs?  (and if, they
> could patch this part of
> the code as well.
> And: from my understanding, nonlinear skb's can only
> happen for packets
> sent by the local host (because zerocopy TCP send
> was used).  Most people
> using netfilter are interested in forwarded packets,
> however.

Our intention is to use iptables for WCCP-enabled 
(Web Cache Control Protocol) 
transparent traffic while other apps using  zero-copy
path. In other words, 
if we are running apps which use zero-copy path and
apps which use iptables
then zero-copy apps gets performance hit. One such
case is that like we have
a WCCP-enabled cache which uses iptable support to
translate inbound and 
outbound connections and the traffic needs ip conn
tracking system. We also 
use zero-copy code path for other apps which do not
require any iptable 
support nor connection tracking nor other proxy
support. The traffic is
getting a big performance hit because we enabled
iptables support.

We are running the zero-copy path with good
performance on 2.4.4 kernel until 
we started using netfilter. Our netfilter traffic is
very low and does not require 
much performance, whereas other apps require lot of
performance gains and do not need
any netfilter monitoring nor have any iptables rules
defined to tracked. And so
netfilter hooks return with NF_ACCEPT but takes a huge
performance hit.



> 
> Summary: Yes, current code is not a good solution. 
> But I'd rather fix
> all of the netfilter/iptables code.
>  

How much effort it takes to move skb_linearize to
netfilter modules atleast to
conntrack,nat and pkt filtering?

One question I have here is that 
As they are coded, don't netfilter modules
(conntrack,NAT,pkt filter) works with non-linear
skbs as, it has all the required IP/TCP/UDP/EE header
in skb? 

Why do netfilter modules need to care whether skb is
linear or non-linear except the one
which tries to use application data and if, is there
one module which uses app data?


Ravi


__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com

Reply via email to