From: Yunsheng Lin <linyunsheng@xxxxxxxxxx> Date: Thu, 2 Mar 2023 10:30:13 +0800 > On 2023/3/2 0:03, Alexander Lobakin wrote: >> __xdp_build_skb_from_frame() state(d): >> >> /* Until page_pool get SKB return path, release DMA here */ >> >> Page Pool got skb pages recycling in April 2021, but missed this >> function. [...] > We both rely on both skb->pp_recycle and page->pp_magic to decide > the page is really from page pool. So there was a few corner case > problem when we are sharing a page for different skb in the driver > level or calling skb_clone() or skb_try_coalesce(). > see: > https://github.com/torvalds/linux/commit/2cc3aeb5ecccec0d266813172fcd82b4b5fa5803 > https://lore.kernel.org/netdev/MW5PR15MB51214C0513DB08A3607FBC1FBDE19@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/t/ > https://lore.kernel.org/netdev/167475990764.1934330.11960904198087757911.stgit@localhost.localdomain/ And they are fixed :D No drivers currently which use Page Pool mix PP pages with non-PP. And it's impossible to trigger try_coalesce() or so at least on cpumap path since we're only creating skbs at that moment, they don't come from anywhere else. > > As the 'struct xdp_frame' also use 'struct skb_shared_info' which is > sharable, see xdp_get_shared_info_from_frame(). > > For now xdpf_clone() does not seems to handling frag page yet, > so it should be fine for now. xdpf_clone() clones a frame to a new full page and doesn't copy its skb_shared_info. > > IMHO we should find a way to use per-page marker, instead of both > per-skb and per-page markers, in order to avoid the above problem > for xdp if xdp has a similar processing as skb, as suggested by Eric. > > https://lore.kernel.org/netdev/CANn89iKgZU4Q+THXupzZi4hETuKuCOvOB=iHpp5JzQTNv_Fg_A@xxxxxxxxxxxxxx/ As Jesper already pointed out, not having a quick way to check whether we have to check ::pp_magic at all can decrease performance. So it's rather a shortcut. > >> >> /* Allow SKB to reuse area used by xdp_frame */ >> xdp_scrub_frame(xdpf); >> Thanks, Olek
