On Thu, 10 Oct 2024 10:44:38 -0700 Mina Almasry wrote: > > > 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. I don't know much about dmabuf but it hinges on the question whether doing DMA sync for device on a dmabuf address is : - a good thing - a noop - a bad thing If it's a good thing or a noop - agreed. Similar question for the sync for CPU. I agree that intuitively it should be all fine. But the fact that dmabuf has a bespoke API for accessing the memory by the CPU makes me worried that there may be assumptions about these addresses not getting randomly fed into the normal DMA API..
