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

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

On Tue, Oct 28, 2025 at 06:53:14PM -0700, Jakub Kicinski wrote:
> On Tue, 28 Oct 2025 09:08:52 +0100 Jesper Dangaard Brouer wrote:
> > > +	xdp->rxq->mem.type = page_pool_page_is_pp(virt_to_head_page(xdp->data)) ?
> > > +				MEM_TYPE_PAGE_POOL : MEM_TYPE_PAGE_SHARED;  
> > 
> > We are slowly killing performance with these paper cuts.  The
> > information we are looking for should be available via skb->pp_recycle,
> > but instead we go lookup the page to deref that memory.  And plus the
> > virt_to_head_page() is more expensive than virt_to_page().
> > 
> > Why don't we check skb->pp_recycle first, and then fall-back to checking
> > the page to catch the mentioned problems?

Hi Jesper, Jakub,

we started with pp_recycle so if we now have agreement regarding its usage
here let me send another revision. My assumption was that generic XDP was
not that performance-sensitive for us, however this helper is going to be
used within {dev,cpu}map, so I agree with your concerns now.

> 
> I still think _all_ frags which may end up here are from the per CPU PP
> since we CoW the skbs. So:

Agree!

> 
> 	DEBUG_NET_WARN_ON_ONCE(!skb->pp_recycle);
> 	xdp->rxq->mem.type = MEM_TYPE_PAGE_POOL;

This has to be conditional as it is fine to use this helper for
MEM_TYPE_PAGE_SHARED, plus the mem type has to be updated per packet.

> 
> ? It is legal to have pp and non-pp frags in a single skb AFAIK.

Ok, but not in this case where data origins from CoW path.

>