Subject: Re: [PATCH v5 bpf 1/2] xdp: introduce xdp_convert_skb_to_buff()

From: Maciej Fijalkowski <[email-masked]>
Date: Thu, 30 Oct 2025 21:22:34 +0100

On Thu, Oct 30, 2025 at 08:25:19AM -0700, Jakub Kicinski wrote:
> On Thu, 30 Oct 2025 13:14:16 +0100 Maciej Fijalkowski wrote:
> > On Wed, Oct 29, 2025 at 04:50:20PM -0700, Jakub Kicinski wrote:
> > > On Wed, 29 Oct 2025 23:13:14 +0100 Maciej Fijalkowski wrote:  
> > > > +	xdp->rxq->mem.type = skb->pp_recycle ? MEM_TYPE_PAGE_POOL :
> > > > +					       MEM_TYPE_PAGE_SHARED;  
> > > 
> > > You really need to stop sending patches before I had a chance 
> > > to reply :/ And this is wrong.  
> > 
> > Why do you say so?
> > 
> > netif_receive_generic_xdp()
> > 	netif_skb_check_for_xdp()
> > 	skb_cow_data_for_xdp() failed
> > 		go through skb linearize path
> > 			returned skb data is backed by kmalloc, not page_pool,
> > 			means mem type for this particular xdp_buff has to be
> > 			MEM_TYPE_PAGE_SHARED
> > 
> > Are we on the same page now?
> 
> No, I think I already covered this, maybe you disagreed and I missed it.
> 
> The mem_type set here is expected to be used only for freeing pages. 
> XDP can only free fagments (when pkt is trimmed), it cannot free the
> head from under the skb. So only fragments matter here, we can ignore
> the head.

...and given that linearize path would make skb a frag-less one...okay -
I'm buying this! :D I have some other thoughts, but I would like to
finally close this pandora's box, you probably have similar feelings.

So plain assignment like:
xdp->rxq->mem.type = MEM_TYPE_PAGE_POOL;

would be fine for you? Plus AI reviewer has kicked me in the nuts on veth
patch so have to send v6 anyways.