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

Robin Murphy
2024-03-01T12:42:42Z

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.