netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Alexander Duyck <alexander.duyck@gmail.com>,
	John Fastabend <john.fastabend@gmail.com>,
	David Miller <davem@davemloft.net>
Cc: brouer@redhat.com, Saeed Mahameed <saeedm@mellanox.com>,
	Tom Herbert <tom@herbertland.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Brenden Blanco <bblanco@gmail.com>
Subject: Focusing the XDP project
Date: Mon, 20 Feb 2017 11:13:43 +0100	[thread overview]
Message-ID: <20170220111343.76f77748@redhat.com> (raw)


First thing to bring in order for the XDP project:

  RX batching is missing.

I don't want to discuss packet page-sizes or multi-port forwarding,
before we have established the most fundamental principal that all
other solution use; RX batching.

Without building in RX batching, from the beginning/now, the XDP
architecture have lost.  As adding features and capabilities, will
just lead us back to the exact same performance problems as before!


Today we already have the 64 packets NAPI budget, but we are not
taking advantage of this. For XDP as long as eBPF always return
XDP_DROP or XDP_TX, then we (falsely) experience the effect of bulking
(as code fits within the icache) and see huge perf boosts.

The initial principal of bulking/batching packets to amortize per
packet costs.  The next step is just as important: Lookup table sizes
(FIB) kills performance again. The solution is implementing a smart
table lookup scheme that prefetch hash table key-cells and afterwards
prefetch data-cells, based on the RX batch of packets.  Notice VPP
revolves around similar tricks, and why it beats DPDK, and why it
scales with 1Millon routes.

I hope I've made it very clear where the focus for XDP should be.
This involves implementing what I call RX-stages in the drivers. While
doing that we can figure out the most optimal data structure for
packet batching.
 I know Saeed is already working on RX-stages for mlx5, and I've tested
the initial version of his patch, and the results are excellent.

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

             reply	other threads:[~2017-02-20 10:13 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-20 10:13 Jesper Dangaard Brouer [this message]
2017-02-20 20:09 ` Focusing the XDP project Alexander Duyck
2017-02-20 22:57   ` Saeed Mahameed
2017-02-20 23:40     ` Alexander Duyck
2017-02-21 23:08       ` Saeed Mahameed
2017-02-21 16:35     ` Tom Herbert
2017-02-21 16:46       ` David Miller
2017-02-21 17:40         ` Tom Herbert
2017-02-21 18:11           ` David Miller
2017-02-21 18:23             ` Tom Herbert
2017-02-21 22:40           ` Saeed Mahameed
2017-02-21 23:04             ` Tom Herbert
2017-02-21 22:29       ` Saeed Mahameed
2017-02-21 22:54         ` Tom Herbert
2017-02-22  9:43           ` Jesper Dangaard Brouer
2017-02-22 17:22             ` Tom Herbert
2017-02-22 21:43               ` Jesper Dangaard Brouer
2017-02-22 22:08                 ` Tom Herbert
2017-02-20 23:39   ` Jesper Dangaard Brouer
2017-02-21  0:39     ` Alexander Duyck

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=20170220111343.76f77748@redhat.com \
    --to=brouer@redhat.com \
    --cc=alexander.duyck@gmail.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=bblanco@gmail.com \
    --cc=davem@davemloft.net \
    --cc=john.fastabend@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=saeedm@mellanox.com \
    --cc=tom@herbertland.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).