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