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]

Message-ID: <20160115150025.13a5db04@redhat.com>
Date:	Fri, 15 Jan 2016 15:00:25 +0100
From:	Jesper Dangaard Brouer <brouer@...hat.com>
To:	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>, brouer@...hat.com
Subject: Re: Optimizing instruction-cache, more packets at each stage

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).

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  Author of http://www.iptv-analyzer.org
  LinkedIn: http://www.linkedin.com/in/brouer