netdev - Re: Optimizing instruction-cache, more packets at each stage

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]

Date:	Fri, 15 Jan 2016 15:38:43 +0100
From:	Felix Fietkau <nbd@...nwrt.org>
To:	Jesper Dangaard Brouer <brouer@...hat.com>,
	David Laight <David.Laight@...LAB.COM>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Alexander Duyck <alexander.duyck@...il.com>,
	Alexei Starovoitov <alexei.starovoitov@...il.com>,
	Daniel Borkmann <borkmann@...earbox.net>,
	Marek Majkowski <marek@...udflare.com>,
	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	Florian Westphal <fw@...len.de>,
	Paolo Abeni <pabeni@...hat.com>,
	John Fastabend <john.r.fastabend@...el.com>
Subject: Re: Optimizing instruction-cache, more packets at each stage

On 2016-01-15 15:00, Jesper Dangaard Brouer wrote:
> On Fri, 15 Jan 2016 13:36:04 +0000
> David Laight <David.Laight@...LAB.COM> wrote:
> 
>> From: Jesper Dangaard Brouer
>> > Sent: 15 January 2016 13:22
>> ...
>> > I want to do some instruction-cache level optimizations.
>> > 
>> > What do I mean by that...
>> > 
>> > The kernel network stack code path (a packet travels) is obviously
>> > larger than the instruction-cache (icache).  Today, every packet
>> > travel individually through the network stack, experiencing the exact
>> > same icache misses (as the previous packet).
>> ...
>> 
>> Is that actually true for modern server processors that have large i-cache.
>> While the total size of the networking code may well be larger, that
>> part used for transmitting data packets will be much be smaller and
>> could easily fit in the icache.
> 
> Yes, exactly. That is what I'm betting on. If I can split it into
> stages (e.g. part used for transmitting) that fits into icache then I
> should see a win.
> 
> The icache is still quite small 32Kb on modern server processors.  I
> don't know if smaller embedded processors also have icache and how
> large they are.  I speculate this approach would also be a benefit for
> them (if they have icache).
All of the router devices that I work with have icache. Typical sizes
are 32 or 64 KiB. FWIW, I'm really looking forward to having such
optimizations in the network stack ;)

- Felix