On Thu, 14 Aug 2025 17:58:21 +0200 Jesper Dangaard Brouer wrote: > Found-by: Dragos Tatulea <dtatulea@xxxxxxxxxx> ENOSUCHTAG? > Reported-by: Chris Arges <carges@xxxxxxxxxxxxxx> > >> The XDP code have evolved since the xdp_set_return_frame_no_direct() > >> calls were added. Now page_pool keeps track of pp->napi and > >> pool-> cpuid. Maybe the __xdp_return [1] checks should be updated? > >> (and maybe it allows us to remove the no_direct helpers). > >> > > So you mean to drop the napi_direct flag in __xdp_return and let > > page_pool_put_unrefed_netmem() decide if direct should be used by > > page_pool_napi_local()? > > Yes, something like that, but I would like Kuba/Jakub's input, as IIRC > he introduced the page_pool->cpuid and page_pool->napi. > > There are some corner-cases we need to consider if they are valid. If > cpumap get redirected to the *same* CPU as "previous" NAPI instance, > which then makes page_pool->cpuid match, is it then still valid to do > "direct" return(?). I think/hope so, but it depends on xdp_return only being called from softirq context.. Since softirqs can't nest if producer and consumer of the page pool pages are on the same CPU they can't race. I'm slightly worried that drivers which don't have dedicated Tx XDP rings will clean it up from hard IRQ when netpoll calls. But that'd be a bug, right? We don't allow XDP processing from IRQ context.
