> Subject: Re: Constantly map and unmap of streaming DMA buffers with
> IOMMU backend might cause serious performance problem
>
> On 2020-05-15 09:19, Song Bao Hua wrote:
> [ snip... nice analysis, but ultimately it's still "doing stuff has more
> overhead
> than not doing stuff" ]
>
> > I am
On 2020-05-15 22:33, Song Bao Hua wrote:
Subject: Re: Constantly map and unmap of streaming DMA buffers with
IOMMU backend might cause serious performance problem
On Fri, May 15, 2020 at 01:10:21PM +0100, Robin Murphy wrote:
Meanwhile, for the safety of buffers, lower-layer drivers need to
> Subject: Re: Constantly map and unmap of streaming DMA buffers with
> IOMMU backend might cause serious performance problem
>
> 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
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
On 2020-05-15 09:19, Song Bao Hua wrote:
[ snip... nice analysis, but ultimately it's still "doing stuff has more
overhead than not doing stuff" ]
I am thinking several possible ways on decreasing or removing the latency of DMA
map/unmap for every single DMA transfer. Meanwhile, "non-strict"
Hi Russell & All,
In many DMA streaming map/unmap use cases, lower-layer device drivers
completely have no idea how and when single/sg buffers are allocated and freed
by upper-layer filesystem, network protocol, mm management system etc. So the
only thing device drivers can do is constantly
