RE: [PATCH v3 0/4] dma-mapping: introduce new dma unmap and sync variants

[Ioana Ciornei]

> Subject: Re: [PATCH v3 0/4] dma-mapping: introduce new dma unmap and sync
> variants
> 
> On 13.11.2019 22:11, David Miller wrote:
> > From: Laurentiu Tudor <laurentiu.tudor@xxxxxxx>
> > Date: Wed, 13 Nov 2019 12:24:17 +0000
> >
> >> From: Laurentiu Tudor <laurentiu.tudor@xxxxxxx>
> >>
> >> This series introduces a few new dma unmap and sync api variants
> >> that, on top of what the originals do, return the virtual address
> >> corresponding to the input dma address. In order to do that a new dma
> >> map op is added, .get_virt_addr that takes the input dma address and
> >> returns the virtual address backing it up.
> >> The second patch adds an implementation for this new dma map op in
> >> the generic iommu dma glue code and wires it in.
> >> The third patch updates the dpaa2-eth driver to use the new apis.
> >
> > The driver should store the mapping in it's private software state if
> > it needs this kind of conversion.
> 
> On this hardware there's no way of conveying additional frame information,
> such as original va/pa behind the dma address. We have also pondered on the
> idea of keeping this in some kind of data structure but could not find a lock-less
> solution which obviously would bring performance to the ground.
> I'll let my colleagues maintaining these ethernet drivers to get into more details,
> if required.
> 

As Laurentiu pointed out before, keeping a mapping in the driver's private data doesn't
seem feasible without a locking mechanism which in turn would be an immense impact
performance wise.

We also feel that instead of hacking our individual drivers we should extend the
core DMA API to also fit this use case, which is exactly what
Laurentiu's patch set is doing.

Our hope is to come to a common understanding of the next steps since this
would unblock some activities currently in the backlog.

Ioana