Thread (21 messages) 21 messages, 7 authors, 2010-01-28

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help