Re: [RFC] dma-mapping: introduce dma_can_skip_unmap()

[Robin Murphy <robin.murphy@arm.com>]

On 2024-03-01 11:50 am, Michael S. Tsirkin wrote:
> On Fri, Mar 01, 2024 at 11:38:25AM +0000, Robin Murphy wrote:
>> Not only is this idea not viable, the entire premise seems flawed - the
>> reasons for virtio needing to use the DMA API at all are highly likely to be
>> the same reasons for it needing to use the DMA API *properly* anyway.
> 
> The idea has nothing to do with virtio per se

Sure, I can see that, but if virtio is presented as the justification 
for doing this then it's the justification I'm going to look at first. 
And the fact is that it *does* seem to have particular significance, 
since having up to 19 DMA addresses involved in a single transfer is 
very much an outlier compared to typical hardware drivers. Furthermore 
the fact that DMA API support was retrofitted to the established virtio 
design means I would always expect it to run up against more challenges 
than a hardware driver designed around the expectation that DMA buffers 
have DMA addresses.

> - we are likely not the
> only driver that wastes a lot of memory (hot in cache, too) keeping DMA
> addresses around for the sole purpose of calling DMA unmap.  On a bunch
> of systems unmap is always a nop and we could save some memory if there
> was a way to find out. What is proposed is an API extension allowing
> that for anyone - not just virtio.

And the point I'm making is that that "always" is a big assumption, and 
in fact for the situations where it is robustly true we already have the 
DEFINE_DMA_UNMAP_{ADDR,LEN} mechanism. I'd consider it rare for DMA 
addresses to be stored in isolation, as opposed to being part of some 
kind of buffer descriptor (or indeed struct scatterlist, for an obvious 
example) that a driver or subsystem still has to keep track of anyway, 
so in general I believe the scope for saving decidedly small amounts of 
memory at runtime is also considerably less than you might be imagining.

Thanks,
Robin.