Constantly map and unmap of streaming DMA buffers with IOMMU backend might cause serious performance problem
hch at lst.de
hch at lst.de
Fri May 15 14:45:22 UTC 2020
On Fri, May 15, 2020 at 01:10:21PM +0100, Robin Murphy wrote:
>> Meanwhile, for the safety of buffers, lower-layer drivers need to make certain the buffers have already been unmapped in iommu before those buffers go back to buddy for other users.
>
> That sounds like it would only have benefit in a very small set of specific
> circumstances, and would be very difficult to generalise to buffers that
> are mapped via dma_map_page() or dma_map_single(). Furthermore, a
> high-level API that affects a low-level driver's interpretation of
> mid-layer API calls without the mid-layer's knowledge sounds like a hideous
> abomination of anti-design. If a mid-layer API lends itself to inefficiency
> at the lower level, it would seem a lot cleaner and more robust to extend
> *that* API for stateful buffer reuse. Failing that, it might possibly be
> appropriate to approach this at the driver level - many of the cleverer
> network drivers already implement buffer pools to recycle mapped SKBs
> internally, couldn't the "zip driver" simply try doing something like that
> for itself?
Exactly. If you upper consumer of the DMA API keeps reusing the same
pages just map them once and use dma_sync_* to transfer ownership as
needed.
More information about the iommu
mailing list