Re: [PATCH RFC net-next 4/4] veth: use generic skb XDP handling

[Maciej Fijalkowski <maciej.fijalkowski@intel.com>]

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?

> 
> I guess what I'm saying is that some performance numbers would help
> here! ;-)
> 
> (I think it might be some accounting bug as well, but I need to re-read
> it!)
> 
> 
> Björn