Netdev List
 help / color / mirror / Atom feed
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
> 

      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