From: Hannes Frederic Sowa <hannes@stressinduktion•org>
To: Jesper Dangaard Brouer <brouer@redhat•com>,
"netdev@vger•kernel.org" <netdev@vger•kernel.org>
Cc: David Miller <davem@davemloft•net>,
Alexander Duyck <alexander.duyck@gmail•com>,
Alexei Starovoitov <alexei.starovoitov@gmail•com>,
Daniel Borkmann <borkmann@iogearbox•net>,
Marek Majkowski <marek@cloudflare•com>,
Florian Westphal <fw@strlen•de>, Paolo Abeni <pabeni@redhat•com>,
John Fastabend <john.r.fastabend@intel•com>
Subject: Re: Optimizing instruction-cache, more packets at each stage
Date: Fri, 15 Jan 2016 14:32:12 +0100 [thread overview]
Message-ID: <5698F4DC.6090302@stressinduktion.org> (raw)
In-Reply-To: <20160115142223.1e92be75@redhat.com>
On 15.01.2016 14:22, Jesper Dangaard Brouer wrote:
>
> Given net-next is closed, we have time to discuss controversial core
> changes right? ;-)
>
> 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).
>
> I imagine that we could process several packets at each stage in the
> packet processing code path. That way making better use of the
> icache.
>
> Today, we already allow NAPI net_rx_action() to process many
> (e.g. up-to 64) packets in the driver RX-poll routine. But the driver
> then calls the "full" stack for every single packet (e.g. via
> napi_gro_receive()) in its processing loop. Thus, trashing the icache
> for every packet.
>
> I have a prove-of-concept patch for ixgbe, which gives me 10% speedup
> on full IP forwarding. (This patch also optimize delaying when I
> touch the packet data, thus it also optimizes data-cache misses). The
> basic idea is that I delay calling ixgbe_rx_skb/napi_gro_receive, and
> allow the RX loop (in ixgbe_clean_rx_irq()) to run more iterations
> before "flushing" the icache (by calling the stack).
>
>
> This was only at the driver level. I also would like some API towards
> the stack. Maybe we could simple pass a skb-list?
>
> Changing / adjusting the stack to support processing in "stages" might
> be more difficult/controversial?
I once tried this up till the vlan layer and error handling got so
complex and complicated that I stopped there. Maybe it is possible in
some separate stages.
This needs redesign of a lot of stuff and while doing so I would switch
from a more stack based approach to build the stack to try out a more
iterative one (see e.g. stack space consumption problems).
Just my 2 cents,
Hannes
next prev parent reply other threads:[~2016-01-15 13:32 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-15 13:22 Optimizing instruction-cache, more packets at each stage Jesper Dangaard Brouer
2016-01-15 13:32 ` Hannes Frederic Sowa [this message]
2016-01-15 14:17 ` Jesper Dangaard Brouer
2016-01-15 13:36 ` David Laight
2016-01-15 14:00 ` Jesper Dangaard Brouer
2016-01-15 14:38 ` Felix Fietkau
2016-01-18 11:54 ` Jesper Dangaard Brouer
2016-01-18 17:01 ` Eric Dumazet
2016-01-25 0:08 ` Florian Fainelli
2016-01-15 20:47 ` David Miller
2016-01-18 10:27 ` Jesper Dangaard Brouer
2016-01-18 16:24 ` David Miller
2016-01-20 22:20 ` Or Gerlitz
2016-01-20 23:02 ` Eric Dumazet
2016-01-20 23:27 ` Tom Herbert
2016-01-21 11:27 ` Jesper Dangaard Brouer
2016-01-21 12:49 ` Or Gerlitz
2016-01-21 13:57 ` Jesper Dangaard Brouer
2016-01-21 18:56 ` David Miller
2016-01-21 22:45 ` Or Gerlitz
2016-01-21 22:59 ` David Miller
2016-01-21 16:38 ` Eric Dumazet
2016-01-21 18:54 ` David Miller
2016-01-24 14:28 ` Jesper Dangaard Brouer
2016-01-24 14:44 ` Michael S. Tsirkin
2016-01-24 17:28 ` John Fastabend
2016-01-25 13:15 ` Bypass at packet-page level (Was: Optimizing instruction-cache, more packets at each stage) Jesper Dangaard Brouer
2016-01-25 17:09 ` Tom Herbert
2016-01-25 17:50 ` John Fastabend
2016-01-25 21:32 ` Tom Herbert
2016-01-25 21:58 ` John Fastabend
2016-01-25 22:10 ` Jesper Dangaard Brouer
2016-01-27 20:47 ` Jesper Dangaard Brouer
2016-01-27 21:56 ` Alexei Starovoitov
2016-01-28 9:52 ` Jesper Dangaard Brouer
2016-01-28 12:54 ` Eric Dumazet
2016-01-28 13:25 ` Eric Dumazet
2016-01-28 16:43 ` Tom Herbert
2016-01-28 2:50 ` Tom Herbert
2016-01-28 9:25 ` Jesper Dangaard Brouer
2016-01-28 12:45 ` Eric Dumazet
2016-01-28 16:37 ` Tom Herbert
2016-01-28 16:43 ` Eric Dumazet
2016-01-28 17:04 ` Jesper Dangaard Brouer
2016-01-24 20:09 ` Optimizing instruction-cache, more packets at each stage Tom Herbert
2016-01-24 21:41 ` John Fastabend
2016-01-24 23:50 ` Tom Herbert
2016-01-21 12:23 ` Jesper Dangaard Brouer
2016-01-21 16:38 ` Tom Herbert
2016-01-21 17:48 ` Eric Dumazet
2016-01-22 12:33 ` Jesper Dangaard Brouer
2016-01-22 14:33 ` Eric Dumazet
2016-01-22 17:07 ` Tom Herbert
2016-01-22 17:17 ` Jesper Dangaard Brouer
2016-02-02 16:13 ` Or Gerlitz
2016-02-02 16:37 ` Eric Dumazet
2016-01-18 16:53 ` Eric Dumazet
2016-01-18 17:36 ` Tom Herbert
2016-01-18 17:49 ` Jesper Dangaard Brouer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5698F4DC.6090302@stressinduktion.org \
--to=hannes@stressinduktion$(echo .)org \
--cc=alexander.duyck@gmail$(echo .)com \
--cc=alexei.starovoitov@gmail$(echo .)com \
--cc=borkmann@iogearbox$(echo .)net \
--cc=brouer@redhat$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=fw@strlen$(echo .)de \
--cc=john.r.fastabend@intel$(echo .)com \
--cc=marek@cloudflare$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=pabeni@redhat$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox