Scatter-gather DMA

Scatter-gather DMA

[Petr Tesařík]

Hi all,

while looking through the kernel code, I've noticed multiple places
which try to convert a DMA address to a struct page pointer just
because a struct page is required by the scatterlist library.

Of course, most of them do the wrong thing (e.g. amba-pl011 simply calls
phys_to_page() on the DMA address), but I wonder if this is merely a
limitation of the API. I mean, some DMA addresses are not even backed
by physical RAM, and then there is generally no struct page, but such
addresses may still be perfectly usable for scatter-gather DMA
transfers.

Is there any reason to use struct page except that the SG list API is
based on page lists?

Any comments welcome.

Petr Tesarik

Re: Scatter-gather DMA

[Christoph Hellwig]

On Tue, Jun 06, 2023 at 04:22:01PM +0200, Petr Tesařík wrote:
> Is there any reason to use struct page except that the SG list API is
> based on page lists?

That's how the scatterlist was historically done, and we have plenty
of places that use the scatterlist for accessing the data using the
page pointer.

Looking back the scatterlist was a rather bad idea as it mixes the
kernel in-memory representation (page, offset, len) with the DMA
information dma_address, dma_len.   I've been proposing forever to
split these two and just use a bio_vec for the kernel mapping
representation and a new phys_vec for the dma_address, dma_len tuples.

And while I've only been talking, Jason apparently already has working
prototype code for this, but I've not seen it yet.

Re: Scatter-gather DMA

[Petr Tesařík]

On Wed, 7 Jun 2023 06:51:56 -0700
Christoph Hellwig <hch@infradead.org> wrote:

> On Tue, Jun 06, 2023 at 04:22:01PM +0200, Petr Tesařík wrote:
> > Is there any reason to use struct page except that the SG list API is
> > based on page lists?  
> 
> That's how the scatterlist was historically done, and we have plenty
> of places that use the scatterlist for accessing the data using the
> page pointer.
> 
> Looking back the scatterlist was a rather bad idea as it mixes the
> kernel in-memory representation (page, offset, len) with the DMA
> information dma_address, dma_len.   I've been proposing forever to
> split these two and just use a bio_vec for the kernel mapping
> representation and a new phys_vec for the dma_address, dma_len tuples.
> 
> And while I've only been talking, Jason apparently already has working
> prototype code for this, but I've not seen it yet.

Thanks for the explanation. The important new piece of information is
that somebody (Jason) is already taking care, so I will not interfere.

Petr T