From: =?unknown-8bit?q?Bj=C3=B6rn_T=C3=B6pel?= <bjorn.topel@gmail.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [PATCH bpf-next 0/6] xsk: exit NAPI loop when AF_XDP Rx ring is full
Date: Fri, 4 Sep 2020 15:53:25 +0200 [thread overview]
Message-ID: <20200904135332.60259-1-bjorn.topel@gmail.com> (raw)
This series addresses a problem that arises when AF_XDP zero-copy is
enabled, and the kernel softirq Rx processing and userland process is
running on the same core.
In contrast to the two-core case, when the userland process/Rx softirq
shares one core, it it very important that the kernel is not doing
unnecessary work, but instead let the userland process run. This has
not been the case.
For the Intel drivers, when the XDP_REDIRECT fails due to a full Rx
ring, the NAPI loop will simply drop the packet and continue
processing the next packet. The XDP_REDIRECT operation will then fail
again, since userland has not been able to empty the full Rx ring.
The fix for this is letting the NAPI loop exit early, if the AF_XDP
socket Rx ring is full.
The outline is as following; The first patch cleans up the error codes
returned by xdp_do_redirect(), so that a driver can figure out when
the Rx ring is full (ENOBUFS). Patch two adds an extended
xdp_do_redirect() variant that returns what kind of map that was used
in the XDP_REDIRECT action. The third patch adds an AF_XDP driver
helper to figure out if the Rx ring was full. Finally, the last three
patches implements the "early exit" support for Intel.
On my machine the "one core scenario Rx drop" performance went from
~65Kpps to 21Mpps. In other words, from "not usable" to
"usable". YMMV.
I prefer to route this series via bpf-next, since it include core
changes, and not only driver changes.
Have a nice weekend!
Bj?rn
Bj?rn T?pel (6):
xsk: improve xdp_do_redirect() error codes
xdp: introduce xdp_do_redirect_ext() function
xsk: introduce xsk_do_redirect_rx_full() helper
i40e, xsk: finish napi loop if AF_XDP Rx queue is full
ice, xsk: finish napi loop if AF_XDP Rx queue is full
ixgbe, xsk: finish napi loop if AF_XDP Rx queue is full
drivers/net/ethernet/intel/i40e/i40e_xsk.c | 23 ++++++++++++++------
drivers/net/ethernet/intel/ice/ice_xsk.c | 23 ++++++++++++++------
drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 23 ++++++++++++++------
include/linux/filter.h | 2 ++
include/net/xdp_sock_drv.h | 9 ++++++++
net/core/filter.c | 16 ++++++++++++--
net/xdp/xsk.c | 2 +-
net/xdp/xsk_queue.h | 2 +-
8 files changed, 75 insertions(+), 25 deletions(-)
base-commit: 8eb629585d2231e90112148009e2a11b0979ca38
--
2.25.1
next reply other threads:[~2020-09-04 13:53 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-04 13:53 =?unknown-8bit?q?Bj=C3=B6rn_T=C3=B6pel?= [this message]
2020-09-04 13:53 ` [Intel-wired-lan] [PATCH bpf-next 1/6] xsk: improve xdp_do_redirect() error codes =?unknown-8bit?q?Bj=C3=B6rn_T=C3=B6pel?=
2020-09-04 13:53 ` [Intel-wired-lan] [PATCH bpf-next 2/6] xdp: introduce xdp_do_redirect_ext() function =?unknown-8bit?q?Bj=C3=B6rn_T=C3=B6pel?=
2020-09-04 13:53 ` [Intel-wired-lan] [PATCH bpf-next 3/6] xsk: introduce xsk_do_redirect_rx_full() helper =?unknown-8bit?q?Bj=C3=B6rn_T=C3=B6pel?=
2020-09-04 15:11 ` Jesper Dangaard Brouer
2020-09-04 15:39 ` =?unknown-8bit?q?Bj=C3=B6rn_T=C3=B6pel?=
2020-09-07 12:45 ` Jesper Dangaard Brouer
2020-09-04 13:53 ` [Intel-wired-lan] [PATCH bpf-next 4/6] i40e, xsk: finish napi loop if AF_XDP Rx queue is full =?unknown-8bit?q?Bj=C3=B6rn_T=C3=B6pel?=
2020-09-04 13:53 ` [Intel-wired-lan] [PATCH bpf-next 5/6] ice, " =?unknown-8bit?q?Bj=C3=B6rn_T=C3=B6pel?=
2020-09-04 13:53 ` [Intel-wired-lan] [PATCH bpf-next 6/6] ixgbe, " =?unknown-8bit?q?Bj=C3=B6rn_T=C3=B6pel?=
2020-09-04 15:35 ` Jesper Dangaard Brouer
2020-09-04 15:54 ` =?unknown-8bit?q?Bj=C3=B6rn_T=C3=B6pel?=
2020-09-04 13:59 ` [Intel-wired-lan] [PATCH bpf-next 0/6] xsk: exit NAPI loop when AF_XDP Rx ring " =?unknown-8bit?q?Bj=C3=B6rn_T=C3=B6pel?=
2020-09-08 10:32 ` Maxim Mikityanskiy
2020-09-08 11:37 ` Magnus Karlsson
2020-09-08 12:21 ` =?unknown-8bit?q?Bj=C3=B6rn_T=C3=B6pel?=
2020-09-09 15:37 ` Jesper Dangaard Brouer
2020-09-04 14:27 ` Jesper Dangaard Brouer
2020-09-04 14:32 ` =?unknown-8bit?q?Bj=C3=B6rn_T=C3=B6pel?=
2020-09-04 23:58 ` Jakub Kicinski
2020-09-07 13:37 ` =?unknown-8bit?q?Bj=C3=B6rn_T=C3=B6pel?=
2020-09-07 18:40 ` Jakub Kicinski
2020-09-08 6:58 ` =?unknown-8bit?q?Bj=C3=B6rn_T=C3=B6pel?=
2020-09-08 17:24 ` Jakub Kicinski
2020-09-08 18:28 ` =?unknown-8bit?q?Bj=C3=B6rn_T=C3=B6pel?=
2020-09-08 18:34 ` Jakub Kicinski
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=20200904135332.60259-1-bjorn.topel@gmail.com \
--to=bjorn.topel@gmail.com \
--cc=intel-wired-lan@osuosl.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