include/linux/skbuff.h | 4 ++-- include/net/xdp.h | 29 ----------------------------- net/core/xdp.c | 19 ++----------------- 3 files changed, 4 insertions(+), 48 deletions(-)
Yeah, I still remember that "Who needs cpumap nowadays" (c), but anyway.
__xdp_build_skb_from_frame() missed the moment when the networking stack
became able to recycle skb pages backed by a page_pool. This was making
e.g. cpumap redirect even less effective than simple %XDP_PASS. veth was
also affected in some scenarios.
A lot of drivers use skb_mark_for_recycle() already, it's been almost
two years and seems like there are no issues in using it in the generic
code too. {__,}xdp_release_frame() can be then removed as it losts its
last user.
Page Pool becomes then zero-alloc (or almost) in the abovementioned
cases, too. Other memory type models (who needs them at this point)
have no changes.
Some numbers on 1 Xeon Platinum core bombed with 27 Mpps of 64-byte
IPv6 UDP, iavf w/XDP[0] (CONFIG_PAGE_POOL_STATS is enabled):
Plain %XDP_PASS on baseline, Page Pool driver:
src cpu Rx drops dst cpu Rx
2.1 Mpps N/A 2.1 Mpps
cpumap redirect (w/o leaving its node) on baseline:
6.8 Mpps 5.0 Mpps 1.8 Mpps
cpumap redirect with skb PP recycling:
7.9 Mpps 5.7 Mpps 2.2 Mpps
+22% (from cpumap redir on baseline)
[0] https://github.com/alobakin/linux/commits/iavf-xdp
Alexander Lobakin (3):
net: page_pool, skbuff: make skb_mark_for_recycle() always available
xdp: recycle Page Pool backed skbs built from XDP frames
xdp: remove unused {__,}xdp_release_frame()
include/linux/skbuff.h | 4 ++--
include/net/xdp.h | 29 -----------------------------
net/core/xdp.c | 19 ++-----------------
3 files changed, 4 insertions(+), 48 deletions(-)
---
From v1[1]:
* make skb_mark_for_recycle() always available, otherwise there are build
failures on non-PP systems (kbuild bot);
* 'Page Pool' -> 'page_pool' when it's about a page_pool instance, not
API (Jesper);
* expanded test system info a bit in the cover letter (Jesper).
[1] https://lore.kernel.org/bpf/20230301160315.1022488-1-aleksander.lobakin@intel.com
--
2.39.2
On 03/03/2023 14.32, Alexander Lobakin wrote:
> Yeah, I still remember that "Who needs cpumap nowadays" (c), but anyway.
>
> __xdp_build_skb_from_frame() missed the moment when the networking stack
> became able to recycle skb pages backed by a page_pool. This was making
> e.g. cpumap redirect even less effective than simple %XDP_PASS. veth was
> also affected in some scenarios.
> A lot of drivers use skb_mark_for_recycle() already, it's been almost
> two years and seems like there are no issues in using it in the generic
> code too. {__,}xdp_release_frame() can be then removed as it losts its
> last user.
> Page Pool becomes then zero-alloc (or almost) in the abovementioned
> cases, too. Other memory type models (who needs them at this point)
> have no changes.
>
> Some numbers on 1 Xeon Platinum core bombed with 27 Mpps of 64-byte
> IPv6 UDP, iavf w/XDP[0] (CONFIG_PAGE_POOL_STATS is enabled):
>
> Plain %XDP_PASS on baseline, Page Pool driver:
>
> src cpu Rx drops dst cpu Rx
> 2.1 Mpps N/A 2.1 Mpps
>
> cpumap redirect (w/o leaving its node) on baseline:
What does it mean "without leaving its node" ?
I interpret this means BPF program CPU redirect to "same" CPU ?
Or does the "node" reference a NUMA node?
>
> 6.8 Mpps 5.0 Mpps 1.8 Mpps
>
> cpumap redirect with skb PP recycling:
Does this test use two CPUs?
>
> 7.9 Mpps 5.7 Mpps 2.2 Mpps
> +22% (from cpumap redir on baseline)
> [0] https://github.com/alobakin/linux/commits/iavf-xdp
>
> Alexander Lobakin (3):
> net: page_pool, skbuff: make skb_mark_for_recycle() always available
> xdp: recycle Page Pool backed skbs built from XDP frames
> xdp: remove unused {__,}xdp_release_frame()
>
> include/linux/skbuff.h | 4 ++--
> include/net/xdp.h | 29 -----------------------------
> net/core/xdp.c | 19 ++-----------------
> 3 files changed, 4 insertions(+), 48 deletions(-)
>
> ---
> From v1[1]:
> * make skb_mark_for_recycle() always available, otherwise there are build
> failures on non-PP systems (kbuild bot);
> * 'Page Pool' -> 'page_pool' when it's about a page_pool instance, not
> API (Jesper);
> * expanded test system info a bit in the cover letter (Jesper).
>
> [1] https://lore.kernel.org/bpf/20230301160315.1022488-1-aleksander.lobakin@intel.com
FYI test_xdp_do_redirect:FAIL:pkt_count_zero unexpected pkt_count_zero: actual 9936 != expected 2 see CI results. It's a submitter job to monitor test results.
From: Alexei Starovoitov <alexei.starovoitov@gmail.com> Date: Fri, 10 Mar 2023 10:33:39 -0800 > FYI > > test_xdp_do_redirect:FAIL:pkt_count_zero unexpected pkt_count_zero: > actual 9936 != expected 2 > > see CI results. > It's a submitter job to monitor test results. Yeah I saw it. Just for some reason I thought it's some CI problems, like "what could possibly go wrong?" :clownface: Sorry >_< The test assumes that only dropped pages get recycled, while this series actually implements recycling for redirected ones as well. I'll dig into this and adjust it on Monday. The code itself is fine :D Thanks, Olek
From: Jesper Dangaard Brouer <jbrouer@redhat.com> Date: Thu, 9 Mar 2023 17:43:51 +0100 [...] >> Some numbers on 1 Xeon Platinum core bombed with 27 Mpps of 64-byte >> IPv6 UDP, iavf w/XDP[0] (CONFIG_PAGE_POOL_STATS is enabled): >> >> Plain %XDP_PASS on baseline, Page Pool driver: >> >> src cpu Rx drops dst cpu Rx >> 2.1 Mpps N/A 2.1 Mpps >> >> cpumap redirect (w/o leaving its node) on baseline: > > What does it mean "without leaving its node" ? > I interpret this means BPF program CPU redirect to "same" CPU ? > Or does the "node" reference a NUMA node? Yes, NUMA node. It's a two-socket system. I redirect to a different physical core, but within one NUMA node. When crossing nodes, results usually are likely worse. > >> >> 6.8 Mpps 5.0 Mpps 1.8 Mpps >> >> cpumap redirect with skb PP recycling: > > Does this test use two CPUs? Yes, one serves interrupt / NAPI polling function and then redirects all packets to a different core, which passes them up the stack. These drops come from that the "source" CPU handles the queue much faster than the "dest" one is able to process (no GRO on cpumap yet* + software checksum computation + ...). Still faster than XDP_PASS when one CPU does everything. * well, there is cpumap GRO implementation in my repo, but without hardware checksum status it's pretty useless and currently there's no hints support in cpumap. So I didn't send it standalone (for now). > >> >> 7.9 Mpps 5.7 Mpps 2.2 Mpps >> +22% (from cpumap redir on baseline) >> [0] https://github.com/alobakin/linux/commits/iavf-xdp [...] Thanks, Olek
From: Alexander Lobakin <aleksander.lobakin@intel.com>
Date: Fri, 3 Mar 2023 14:32:29 +0100
> Yeah, I still remember that "Who needs cpumap nowadays" (c), but anyway.
>
> __xdp_build_skb_from_frame() missed the moment when the networking stack
> became able to recycle skb pages backed by a page_pool. This was making
> e.g. cpumap redirect even less effective than simple %XDP_PASS. veth was
> also affected in some scenarios.
> A lot of drivers use skb_mark_for_recycle() already, it's been almost
> two years and seems like there are no issues in using it in the generic
> code too. {__,}xdp_release_frame() can be then removed as it losts its
> last user.
> Page Pool becomes then zero-alloc (or almost) in the abovementioned
> cases, too. Other memory type models (who needs them at this point)
> have no changes.
Ping?
The discussion in the v1 thread is unrelated to the patch subject :D
[...]
Thanks,
Olek
© 2016 - 2026 Red Hat, Inc.