[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251028185314.1ad62578@kernel.org>
Date: Tue, 28 Oct 2025 18:53:14 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jesper Dangaard Brouer <hawk@...nel.org>
Cc: Maciej Fijalkowski <maciej.fijalkowski@...el.com>, bpf@...r.kernel.org,
ast@...nel.org, daniel@...earbox.net, netdev@...r.kernel.org,
magnus.karlsson@...el.com, aleksander.lobakin@...el.com,
ilias.apalodimas@...aro.org, toke@...hat.com, lorenzo@...nel.org,
syzbot+ff145014d6b0ce64a173@...kaller.appspotmail.com, Ihor Solodrai
<ihor.solodrai@...ux.dev>, Octavian Purdila <tavip@...gle.com>
Subject: Re: [PATCH v4 bpf 1/2] xdp: introduce xdp_convert_skb_to_buff()
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?
I still think _all_ frags which may end up here are from the per CPU PP
since we CoW the skbs. So:
DEBUG_NET_WARN_ON_ONCE(!skb->pp_recycle);
xdp->rxq->mem.type = MEM_TYPE_PAGE_POOL;
? It is legal to have pp and non-pp frags in a single skb AFAIK.
Powered by blists - more mailing lists