Subject: Re: [PATCH bpf 2/2] veth: update mem type in xdp_buff

From: Jakub Kicinski <[email-masked]>
Date: Tue, 7 Oct 2025 18:11:53 -0700

On Tue, 7 Oct 2025 16:59:21 +0200 Maciej Fijalkowski wrote:
> > My thinking was that we should try to bake the rxq into "conversion"
> > APIs, draft diff below, very much unfinished and I'm probably missing
> > some cases but hopefully gets the point across:  
> 
> That is not related IMHO. The bugs being fixed have existing rxqs. It's
> just the mem type that needs to be correctly set per packet.
> 
> Plus we do *not* convert frame to buff here which was your initial (on
> point) comment WRT onstack rxqs. Traffic comes as skbs from peer's
> ndo_start_xmit(). What you're referring to is when source is xdp_frame (in
> veth case this is when ndo_xdp_xmit or XDP_TX is used).

I guess we're slipping into a philosophical discussion but I'd say 
that the problem is that rxq stores part of what is de facto xdp buff
state. It is evacuated into the xdp frame when frame is constructed,
as packet is detached from driver context. We need to reconstitute it
when we convert frame (skb, or anything else) back info an xdp buff.

xdp_convert_buff_to_frame() and xdp_convert_frame_to_buff() should be
a mirror image of each other, to put it more concisely.

> However the problem pointed out by AI (!) is something we should fix as
> for XDP_{TX,REDIRECT} xdp_rxq_info is overwritten and mem type update is
> lost.

> > +/* Initialize an xdp_buff from an skb.
> > + *
> > + * Note: if skb has frags skb_cow_data_for_xdp() must be called first,
> > + * or caller must otherwise guarantee that the frags come from a page pool
> > + */
> > +static inline
> > +void xdp_convert_skb_to_buff(const struct xdp_frame *frame,
> > +			     struct xdp_buff *xdp, struct xdp_rxq_info *rxq)  
> 
> I would expect to get skb as an input here

Joł. Don't nit pick my draft diff :D It's not meant as a working patch.