From: "Björn Töpel" <bjorn@kernel.org>
To: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Cc: netdev@vger.kernel.org, bpf@vger.kernel.org,
magnus.karlsson@intel.com, stfomichev@gmail.com, kuba@kernel.org,
pabeni@redhat.com, horms@kernel.org, lorenzo@kernel.org,
hawk@kernel.org, toke@redhat.com
Subject: Re: [PATCH RFC net-next 4/4] veth: use generic skb XDP handling
Date: Wed, 13 May 2026 13:31:37 +0200 [thread overview]
Message-ID: <87zf23im06.fsf@all.your.base.are.belong.to.us> (raw)
In-Reply-To: <agNeGjzEsYRaqqFf@boxer>
Maciej Fijalkowski <maciej.fijalkowski@intel.com> writes:
> On Tue, May 12, 2026 at 04:32:43PM +0200, Björn Töpel wrote:
>> Maciej Fijalkowski <maciej.fijalkowski@intel.com> writes:
>>
>> > veth currently runs XDP for skb-backed packets by constructing an
>> > xdp_buff and then, for XDP_TX and XDP_REDIRECT, converting that
>> > skb-backed xdp_buff into an xdp_frame. The backing memory is still
>> > skb-owned, so veth has to pin the skb data and frags manually before
>> > consuming the skb.
>> >
>> > Use the generic skb XDP helper for skb-backed packets instead. This
>> > keeps skb-backed packets on the skb generic XDP path: XDP_REDIRECT uses
>> > xdp_do_generic_redirect() and XDP_TX uses generic_xdp_tx(). Packets that
>> > already arrive as xdp_frames keep using the existing veth xdp_frame path.
>> >
>> > veth still provides its own page_pool and xdp_rxq_info through struct
>> > xdp_generic_ctx. It also keeps using struct veth_xdp_buff storage so
>> > metadata kfuncs that need the skb continue to work after a possible skb
>> > COW.
>>
>>
>> Hmm, so now if veth with native XDP redirects to a native XDP NIC, we'll
>> end up in the generic path? We'll loose some bulking capabilities as
>> well, but maybe that's OK.
>
> Hi Bjorn - thanks a lot for taking a look at these changes!
>
> This touches a path where receiver has XDP prog loaded but sender used
> ndo_start_xmit() to produce skbs onto another end of veth pair; these skbs
> are then stored within ptr_ring where receiver picks them up. Native XDP
> still has bulking, however the skb path has a little bit of back-and-forth
> juggle between skb<->xdp_frame conversion. Now I got rid of these
> conversions but also of home-grown generic XDP path as well as bulking and
> the end result seems to land in the same performance results.
>
> Does it make sense to you?
Hmm! Thanks! ...but doesn't this change the semantics of redirect, for
skb-input/native case?
target of redirect before (skb-input) after (skb-input)
real NIC via devmap ndo_xdp_xmit(), bulked, XDP TX queue netdev_start_xmit(), regular qdisc/TX path
cpumap xdp_frame on remote CPU's ptr_ring skb on remote CPU's softnet backlog
AF_XDP socket native (potentially ZC) xsk_generic_rcv (copy, generic)
veth peer (devmap) xdp_frame into peer's xdp_ring skb into peer's xdp_ring (same ring, skb tag)
(Let me re-read it!)
Björn
next prev parent reply other threads:[~2026-05-13 11:31 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-09 8:48 [PATCH RFC net-next 0/4] xdp: reuse generic skb XDP handling for veth Maciej Fijalkowski
2026-05-09 8:48 ` [PATCH RFC net-next 1/4] xdp: add mixed page_pool/page_shared memory type Maciej Fijalkowski
2026-05-09 8:48 ` [PATCH RFC net-next 2/4] xdp: return status from generic_xdp_tx() Maciej Fijalkowski
2026-05-12 12:57 ` Björn Töpel
2026-05-12 17:13 ` Maciej Fijalkowski
2026-05-09 8:48 ` [PATCH RFC net-next 3/4] xdp: split generic XDP skb handling Maciej Fijalkowski
2026-05-09 8:48 ` [PATCH RFC net-next 4/4] veth: use generic skb XDP handling Maciej Fijalkowski
2026-05-12 14:32 ` Björn Töpel
2026-05-12 17:06 ` Maciej Fijalkowski
2026-05-13 11:31 ` Björn Töpel [this message]
2026-05-12 12:55 ` [PATCH RFC net-next 0/4] xdp: reuse generic skb XDP handling for veth Björn Töpel
2026-05-12 17:12 ` Maciej Fijalkowski
2026-05-14 5:13 ` Jesper Dangaard Brouer
2026-05-15 0:54 ` 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=87zf23im06.fsf@all.your.base.are.belong.to.us \
--to=bjorn@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=hawk@kernel.org \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=lorenzo@kernel.org \
--cc=maciej.fijalkowski@intel.com \
--cc=magnus.karlsson@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=stfomichev@gmail.com \
--cc=toke@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.