On 22.03.2025 01:41, Jason Gunthorpe wrote: > On Fri, Mar 21, 2025 at 12:52:30AM +0100, Marek Szyprowski wrote: >>> Christoph's vision was to make a performance DMA API path that could >>> be used to implement any scatterlist-like data structure very >>> efficiently without having to teach the DMA API about all sorts of >>> scatterlist-like things. >> Thanks for explaining one more motivation behind this patchset! > Sure, no problem. > > To close the loop on the bigger picture here.. > > When you put the parts together: > > 1) dma_map_sg is the only API that is both performant and fully > functional > > 2) scatterlist is a horrible leaky design and badly misued all over > the place. When Logan added SG_DMA_BUS_ADDRESS it became quite > clear that any significant changes to scatterlist are infeasible, > or at least we'd break a huge number of untestable legacy drivers > in the process. > > 3) We really want to do full featured performance DMA *without* a > struct page. This requires changing scatterlist, inventing a new > scatterlist v2 and DMA map for it, or this idea here of a flexible > lower level DMA API entry point. > > Matthew has been talking about struct-pageless for a long time now > from the block/mm direction using folio & memdesc and this is > meeting his work from the other end of the stack by starting to > build a way to do DMA on future struct pageless things. This is > going to be huge multi-year project but small parts like this need > to be solved and agreed to make progress. Again, thanks for another summary! > 4) In the immediate moment we still have problems in VFIO, RDMA, and > DRM managing P2P transfers because dma_map_resource/page() don't > properly work, and we don't have struct pages to use > dma_map_sg(). Hacks around the DMA API have been in the kernel for > a long time now, we want to see a properly architected solution. What kind of a fix is needed to dma_map_resource()/dma_unmap_resource() API to make it usable with P2P DMA? It looks that this API is closest to the mentioned dma_map_phys() and has little clients, so potentially changing the function signature should be quite easy. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
