Re: [PATCH v5] rps: Receive Packet Steering
From: David Miller <davem@davemloft.net>
Date: 2010-01-15 09:26:06
Also in:
netfilter-devel
From: Changli Gao <redacted> Date: Fri, 15 Jan 2010 17:20:43 +0800
On Fri, Jan 15, 2010 at 4:49 PM, David Miller [off-list ref] wrote:quoted
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.