From: Jesper Dangaard Brouer <brouer@redhat.com>
To: netdev@vger.kernel.org, Daniel Borkmann <borkmann@iogearbox.net>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Jesper Dangaard Brouer <brouer@redhat.com>
Cc: "Christoph Hellwig" <hch@infradead.org>,
BjörnTöpel <bjorn.topel@intel.com>,
"Magnus Karlsson" <magnus.karlsson@intel.com>
Subject: [bpf-next PATCH 0/4] xdp: introduce bulking for ndo_xdp_xmit API
Date: Wed, 09 May 2018 15:12:54 +0200 [thread overview]
Message-ID: <152587152136.20423.14493673928480468024.stgit@firesoul> (raw)
This patchset change ndo_xdp_xmit API to take a bulk of xdp frames.
When kernel is compiled with CONFIG_RETPOLINE, every indirect function
pointer (branch) call hurts performance. For XDP this have a huge
negative performance impact.
This patchset reduce the needed (indirect) calls to ndo_xdp_xmit, but
also prepares for further optimizations. The DMA APIs use of indirect
function pointer calls is the primary source the regression. It is
left for a followup patchset, to use bulking calls towards the DMA API
(via the scatter-gatter calls).
The other advantage of this API change is that drivers can easier
amortize the cost of any sync/locking scheme, over the bulk of
packets. The assumption of the current API is that the driver
implemementing the NDO will also allocate a dedicated XDP TX queue for
every CPU in the system. Which is not always possible or practical to
configure. E.g. ixgbe cannot load an XDP program on a machine with
more than 96 CPUs, due to limited hardware TX queues. E.g. virtio_net
is hard to configure as it requires manually increasing the
queues. E.g. tun driver chooses to use a per XDP frame producer lock
modulo smp_processor_id over avail queues.
---
Jesper Dangaard Brouer (4):
bpf: devmap introduce dev_map_enqueue
bpf: devmap prepare xdp frames for bulking
xdp: add tracepoint for devmap like cpumap have
xdp: change ndo_xdp_xmit API to support bulking
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 26 ++++-
drivers/net/ethernet/intel/i40e/i40e_txrx.h | 2
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 21 +++-
drivers/net/tun.c | 37 ++++---
drivers/net/virtio_net.c | 66 +++++++++---
include/linux/bpf.h | 15 ++-
include/linux/netdevice.h | 14 ++-
include/net/xdp.h | 1
include/trace/events/xdp.h | 50 +++++++++
kernel/bpf/devmap.c | 134 ++++++++++++++++++++++++-
net/core/filter.c | 19 +---
net/core/xdp.c | 14 ++-
samples/bpf/xdp_monitor_kern.c | 49 +++++++++
samples/bpf/xdp_monitor_user.c | 69 +++++++++++++
14 files changed, 436 insertions(+), 81 deletions(-)
next reply other threads:[~2018-05-09 13:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-09 13:12 Jesper Dangaard Brouer [this message]
2018-05-09 13:12 ` [bpf-next PATCH 1/4] bpf: devmap introduce dev_map_enqueue Jesper Dangaard Brouer
2018-05-10 9:10 ` kbuild test robot
2018-05-10 9:10 ` kbuild test robot
2018-05-09 13:13 ` [bpf-next PATCH 2/4] bpf: devmap prepare xdp frames for bulking Jesper Dangaard Brouer
2018-05-09 13:13 ` [bpf-next PATCH 3/4] xdp: add tracepoint for devmap like cpumap have Jesper Dangaard Brouer
2018-05-09 13:13 ` [bpf-next PATCH 4/4] xdp: change ndo_xdp_xmit API to support bulking Jesper Dangaard Brouer
2018-05-10 8:10 ` kbuild test robot
2018-05-10 9:03 ` kbuild test robot
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=152587152136.20423.14493673928480468024.stgit@firesoul \
--to=brouer@redhat.com \
--cc=alexei.starovoitov@gmail.com \
--cc=bjorn.topel@intel.com \
--cc=borkmann@iogearbox.net \
--cc=hch@infradead.org \
--cc=magnus.karlsson@intel.com \
--cc=netdev@vger.kernel.org \
/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