netdev - Re: [PATCH v5] rps: Receive Packet Steering

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20100115.012613.223485835.davem@davemloft.net>
Date:	Fri, 15 Jan 2010 01:26:13 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	xiaosuo@...il.com
Cc:	eric.dumazet@...il.com, therbert@...gle.com,
	netdev@...r.kernel.org, netfilter-devel@...r.kernel.org
Subject: Re: [PATCH v5] rps: Receive Packet Steering

From: Changli Gao <xiaosuo@...il.com>
Date: Fri, 15 Jan 2010 17:20:43 +0800

> On Fri, Jan 15, 2010 at 4:49 PM, David Miller <davem@...emloft.net> 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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html