From: Changli Gao <xiaosuo@xxxxxxxxx> Date: Fri, 15 Jan 2010 17:20:43 +0800 > On Fri, Jan 15, 2010 at 4:49 PM, David Miller <davem@xxxxxxxxxxxxx> wrote: >> >> Actually, no thanks. Have you actually taken a look at >> ipv6_skip_exthdr()? >> >> Do that, then tell me that you want the extra function call, plus all >> of the processing and data touching that that function does, just to >> handle the case that there "might" be ipv6 extension headers there. >> > > I don't think ipv6_skip_exthdr() is too weight. If there isn't any > extra header, only some compare and jump instruments are added, and no > more data references. If there are some headers, I think distributing > packets among CPUs is more important than the extra cost introduced by > calling ipv6_skip_exthdr(). Calling a function is expensive. What was now a leaf function deep in the call chain, will no longer be, so GCC will need to push all live registers onto the stack, then reload them back into registers when ipv6_skip_exthdr() returns. And that function is expensive, it's a lot of code that %99 of the time serves no purpose at all. This will be executed for every single packet we process, and Linux can process millions of packets per second, so every cycle and every memory reference matters. > Maybe they don't know it.If it was a performance regression, I think > more people might pay attention on it. And we can address such a problem at that time. Can you show a real life setup that sees ipv6 packets with extension headers and would be effected by this? Really, I do not want to bloat up this path with useless code execution when for all practical purposes it really doesn't matter. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
