From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
To: Slawomir Stepien <sst@poczta.fm>
Cc: netdev@vger.kernel.org, bpf@vger.kernel.org,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Eric Dumazet" <edumazet@kernel.org>,
"David S . Miller" <davem@davemloft.net>,
"Andrew Lunn" <andrew+netdev@lunn.ch>,
"Simon Horman" <horms@kernel.org>,
"Björn Töpel" <bjorn@kernel.org>,
"Jesper Dangaard Brouer" <hawk@kernel.org>,
"Toke Høiland-Jørgensen" <toke@redhat.com>,
"Lorenzo Bianconi" <lorenzo@kernel.org>,
"Magnus Karlsson" <magnus.karlsson@intel.com>,
"Stanislav Fomichev" <sdf@fomichev.me>,
"Alexei Starovoitov" <ast@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"John Fastabend" <john.fastabend@gmail.com>,
"Andrii Nakryiko" <andrii@kernel.org>,
"Eduard Zingerman" <eddyz87@gmail.com>,
"Kumar Kartikeya Dwivedi" <memxor@gmail.com>,
"Martin KaFai Lau" <martin.lau@linux.dev>,
"Song Liu" <song@kernel.org>,
"Yonghong Song" <yonghong.song@linux.dev>,
"Jiri Olsa" <jolsa@kernel.org>,
"Emil Tsalapatis" <emil@etsalapatis.com>,
"Ihor Solodrai" <ihor.solodrai@linux.dev>,
"Vladimir Oltean" <vladimir.oltean@nxp.com>,
"Tianyi Gao" <tianyi@cloudflare.com>,
"Liang Chen" <liangchen.linux@gmail.com>,
"Yunsheng Lin" <linyunsheng@huawei.com>,
"huangjie . albert" <huangjie.albert@bytedance.com>
Subject: Re: [PATCH RFC net-next v2 0/4] xdp: reuse generic skb XDP handling for veth
Date: Tue, 10 Nov 2026 13:48:51 +0100 [thread overview]
Message-ID: <avMSs9oopzc1SAnw@boxer> (raw)
In-Reply-To: <20261110101941.1059662-1-sst@poczta.fm>
On Tue, Nov 10, 2026 at 11:19:37AM +0100, Slawomir Stepien wrote:
> Hi,
>
> this is v2 of Maciej's RFC [1], which makes veth run XDP on skb-backed
> packets through the generic skb XDP path instead of converting them
> into xdp_frames for XDP_TX and XDP_REDIRECT. The patches are Maciej's;
> I addressed the review of v1 and measured the performance, which was
> the main open question there. Changes I made are noted in [sst: ...]
> lines in each commit message.
>
> The motivation is unchanged: veth pins the skb data with plain page
> references (veth_xdp_get()) to build an xdp_frame from an skb, and the
> rxq memory type it reports does not match memory that was copied into
> a page_pool, which makes the AF_XDP selftests splat when a program
> shrinks a multi-buffer packet. With this series, pages copied into
> veth's page_pool are recycled (0 rx_pp_recycle_released_ref, was
> ~4.8M/s in the benchmark below).
>
> Dependencies
> ============
>
> The series applies to net-next with these two net series applied
> first (prerequisite-patch-id below):
>
> - Tianyi Gao, "net: fix mac_len of skbs copied by generic XDP" (1/2)
> [2]. Without it, cpumap redirect of skbs that veth copied drops
> every packet once veth uses the generic path.
> - Vladimir Oltean, "net: pass the XDP action to generic_xdp_tx() for
> tracing" and "net: validate xmit skbs in generic_xdp_tx()" [3].
> Patch 2/4 changes the same function.
>
> Changes in v2
> =============
>
> 1/4: MEM_TYPE_PAGE_POOL_OR_SHARED renamed to MEM_TYPE_MIXED (Björn);
> comment on what the type means.
> 2/4: Rebased on Vladimir's series. The redirect callers in devmap and
> filter still return success: generic_xdp_tx() frees and counts a
> failed skb itself, so propagating the error would free it twice
> (Björn asked why the error is not propagated).
> 3/4: One skb_needs_xdp_cow() predicate for generic XDP and veth
> (shared, cloned, nonlinear or headroom too small) instead of a
> per-caller callback and INDIRECT_CALL_2 (Jakub). The
> skb_head_is_locked() check is gone, it would copy every locally
> generated skb. Copies go to the caller's page_pool with
> skb_pp_cow_data() also for programs without frags support (found
> by the xdp_metadata selftest).
> 4/4: Commit message describes how XDP_TX/XDP_REDIRECT change for
> skb-backed packets (Björn's table). A failed skb XDP_TX is counted
> once, in the device's tx_dropped (Sashiko). veth sets
> skb->mac_len before running generic XDP, as
> __netif_receive_skb_core() does; without it cpumap redirect of
> veth skbs is dropped.
That looks sane.
>
> Performance
> ===========
>
> QEMU/KVM, 8 vCPUs, minimal config without debug options. pktgen sends
> skbs into veth v0, the XDP program runs on the peer v1 (skb path).
> Packets/s delivered to the destination, median of 12 runs of 8 s over
> 4 alternating boots per kernel, 95% bootstrap confidence intervals
> within about +-2%. Base: v7.4-rc1+ (f66469d9905b) with the
> dependencies above.
>
> 64 B 8000 B (3 frags)
> XDP_TX 4.49 -> 4.04 Mpps (-10%) 2.25 -> 1.87 (-17%)
> REDIRECT devmap -> veth 4.30 -> 3.95 (-8%) 2.18 -> 1.81 (-17%)
> REDIRECT cpumap 4.49 -> 4.47 (0%) 2.02 -> 2.27 (+12%)
> XDP_DROP (native veth) 5.65 -> 5.42 (-4%) 2.82 -> 2.71 (-4%)
> XDP_DROP (xdpgeneric) 5.63 -> 5.83 (+4%) 2.94 -> 3.00 (+2%)
>
> (cpumap 8000 B base: base without Vladimir's series, which does not
> touch that path; 3 of the 12 runs of the other base kernel stalled.)
>
> cpumap avoids the skb -> xdp_frame -> skb round trip. XDP_TX and
> devmap redirect to veth are slower for two reasons:
>
> - no bulking: one ndo_start_xmit() per skb instead of ndo_xdp_xmit()
> with up to 16 frames;
> - at 8000 B the receiving veth copies the packet a second time.
> Before, it got an xdp_frame; now it gets an skb with frags, and
> nonlinear skbs are always copied (kprobe on skb_pp_cow_data(): 1
> copy per packet before, 2 after).
>
> Vladimir's validation itself costs about 3% at 64 B on these two
> paths and nothing measurable elsewhere.
>
> Questions
> =========
>
> - Is the XDP_TX/devmap regression acceptable for the simpler and
> correct memory handling, or should it be fixed first? Options we
> see: skb-list bulking in the generic TX path (Jesper measured +30%
> with xmit_more), and not copying nonlinear skbs whose frags are
> already page_pool pages. Raising veth's needed_headroom (Jesper)
> only helps linear skbs from senders that honour it; pktgen skbs are
> shared and always copied, so the benchmark above cannot show it.
> We left all three for follow-ups.
Thanks for these tests, for some reason my local benchmarks were not
showing such differences and also xmit_more was not giving me much of a
bump.
The impact is noticeable I'd say. Could you see how xmit_more change would
affect the benchmarks?
> - MEM_TYPE_MIXED vs. separate memory types per source (Jesper).
> - The redirect semantics change in 4/4 (Björn).
>
> Testing
> =======
>
> Each commit builds with W=1 without new warnings, checkpatch --strict is
> clean. test_progs -t ns_xsk,xdp passes; test_xsk.sh shows the same DRV
> XDP_ADJUST_TAIL_GROW failures (also with busy poll) as without the
> series. Reproducers for shrinking frags in generic and veth XDP, XDP_TX
> of multi-buffer packets, devmap egress programs and bpf_prog_test_run
> after generic XDP on lo pass without kernel warnings.
>
> The scripts, kernel configs and raw logs behind the numbers and tests
> above are in [4], with instructions to rerun them.
>
> AI disclosure: the review changes, the tests and the benchmark were
> prepared with help from an AI coding assistant (Claude); I reviewed
> and tested all changes.
>
> [1] https://lore.kernel.org/all/20260509084858.773921-1-maciej.fijalkowski@intel.com/
> [2] https://lore.kernel.org/all/20261103200036.65764-3-tianyi@cloudflare.com/
> [3] https://lore.kernel.org/all/20261030114753.185281-1-vladimir.oltean@nxp.com/
> [4] https://github.com/s-stepien/xdp-rfc
>
> Thanks,
> Slawomir
>
> Maciej Fijalkowski (4):
> xdp: add mixed page_pool/page_shared memory type
> xdp: return status from generic_xdp_tx()
> xdp: split generic XDP skb handling
> veth: use generic skb XDP handling
>
> drivers/net/veth.c | 191 +++++++++-----------------------------
> include/linux/netdevice.h | 33 ++++++-
> include/net/xdp.h | 1 +
> net/core/dev.c | 122 ++++++++++++++++++------
> net/core/filter.c | 7 ++
> net/core/xdp.c | 54 ++++++++++-
> 6 files changed, 222 insertions(+), 186 deletions(-)
>
>
> base-commit: fa5196392691051963726787944db872420dfa75
> prerequisite-patch-id: 7db3107f14b28c509845871045e6af93b7e267bc
> prerequisite-patch-id: 40350101232837c5a38ba1662825228d01734b39
> prerequisite-patch-id: 0b57f8c2a409470b1ddf8df747d906d5d3dbd9f3
> --
> 2.56.0
>
prev parent reply other threads:[~2026-11-10 12:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 10:19 [PATCH RFC net-next v2 0/4] xdp: reuse generic skb XDP handling for veth Slawomir Stepien
2026-11-10 10:19 ` [PATCH RFC net-next v2 1/4] xdp: add mixed page_pool/page_shared memory type Slawomir Stepien
2026-11-10 10:19 ` [PATCH RFC net-next v2 2/4] xdp: return status from generic_xdp_tx() Slawomir Stepien
2026-11-10 10:19 ` [PATCH RFC net-next v2 3/4] xdp: split generic XDP skb handling Slawomir Stepien
2026-11-10 10:19 ` [PATCH RFC net-next v2 4/4] veth: use generic skb XDP handling Slawomir Stepien
2026-11-10 12:48 ` Maciej Fijalkowski [this message]
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=avMSs9oopzc1SAnw@boxer \
--to=maciej.fijalkowski@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bjorn@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=eddyz87@gmail.com \
--cc=edumazet@kernel.org \
--cc=emil@etsalapatis.com \
--cc=hawk@kernel.org \
--cc=horms@kernel.org \
--cc=huangjie.albert@bytedance.com \
--cc=ihor.solodrai@linux.dev \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kuba@kernel.org \
--cc=liangchen.linux@gmail.com \
--cc=linyunsheng@huawei.com \
--cc=lorenzo@kernel.org \
--cc=magnus.karlsson@intel.com \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
--cc=song@kernel.org \
--cc=sst@poczta.fm \
--cc=tianyi@cloudflare.com \
--cc=toke@redhat.com \
--cc=vladimir.oltean@nxp.com \
--cc=yonghong.song@linux.dev \
/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