Re: [PATCH v7 00/17] Provide a new two step DMA mapping API
From: Marek Szyprowski
Date: Fri Mar 28 2025 - 10:19:52 EST
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