On Wed, Oct 9, 2024 at 5:01 PM Jakub Kicinski <kuba@xxxxxxxxxx> wrote: > > On Thu, 10 Oct 2024 00:37:49 +0900 Taehee Yoo wrote: > > > Yes, but netmem_ref can be either a net_iov or a normal page, > > > and skb_add_rx_frag_netmem() and similar helpers should automatically > > > set skb->unreadable or not. > > > > > > IOW you should be able to always use netmem-aware APIs, no? > > > > I'm not sure the update skb->unreadable flag is possible because > > frag API like skb_add_rx_frag_netmem(), receives only frag, not skb. > > How about an additional API to update skb->unreadable flag? > > skb_update_unreadable() or skb_update_netmem()? > > Ah, the case where we don't get skb is because we're just building XDP > frame at that stage. And XDP can't be netmem. > > In that case switching to skb_frag_fill_netmem_desc() should be enough. > > > > > The reason why the branch exists here is the PP_FLAG_ALLOW_UNREADABLE_NETMEM > > > > flag can't be used with PP_FLAG_DMA_SYNC_DEV. > > > > > > Hm. Isn't the existing check the wrong way around? Is the driver > > > supposed to sync the buffers for device before passing them down? > > > > I haven't thought the failure of PP_FLAG_DMA_SYNC_DEV > > for dmabuf may be wrong. > > I think device memory TCP is not related to this flag. > > So device memory TCP core API should not return failure when > > PP_FLAG_DMA_SYNC_DEV flag is set. > > How about removing this condition check code in device memory TCP core? > > I think we need to invert the check.. > Mina, WDYT? > On a closer look, my feeling is similar to Taehee, PP_FLAG_DMA_SYNC_DEV should be orthogonal to memory providers. The memory providers allocate the memory and provide the dma-addr, but need not dma-sync the dma-addr, right? The driver can sync the dma-addr if it wants and the driver can delegate the syncing to the pp via PP_FLAG_DMA_SYNC_DEV if it wants. AFAICT I think the check should be removed, not inverted, but I could be missing something. -- Thanks, Mina
