bus_dmamap_sync() for bounced client buffers from user address space

[Jason Harmening]

On 04/25/15 13:18, Konstantin Belousov wrote:
> On Sat, Apr 25, 2015 at 12:55:13PM -0500, Jason Harmening wrote:
>> Ah, that looks much better.  A few things though:
>> 1) _bus_dmamap_load_ma (note the underscore) is still part of the MI/MD
>> interface, which we tell drivers not to use.  It looks like it's
>> implemented for every arch though.  Should there be a public and
>> documented bus_dmamap_load_ma ?
> Might be yes.  But at least one consumer of the KPI must appear before
> the facility is introduced.

Could some of the GART/GTT code consume that?

>> 2) There is a bus_dmamap_load_ma_triv that's part of the MI interface,
>> but it's not documented, and it seems like it would be suboptimal in
>> certain cases, such as when dmar is enabled.
> When DMAR is enabled, bus_dmamap_load_triv() should not be used.
> It should not be used directly even when not.  Drivers should use
> bus_dmamap_load_ma(), and implementation redirects to _triv() if
> needed.
>
> The _triv() is the helper to allow bus_dmamap_load_ma() to exists
> on architectures which cannot implement, on not yet implemented,
> proper page array load op.
Yes, I noticed the same thing.  I'm not sure why _triv() is treated as
part of the public API and not prefixed with an underscore and a comment
not to use it in drivers.
>> 3) Using bus_dmamap_load_ma would mean always using physcopy for bounce
>> buffers...seems like the sfbufs would slow things down ?
> For amd64, sfbufs are nop, due to the direct map.  But, I doubt that
> we can combine bounce buffers and performance in the single sentence.
In fact the amd64 implementation of uiomove_fromphys doesn't use sfbufs
at all thanks to the direct map.  sparc64 seems to avoid sfbufs as much
as possible too.  I don't know what arm64/aarch64 will be able to use. 
Those seem like the platforms where bounce buffering would be the most
likely, along with i386 + PAE.  They might still be used on 32-bit
platforms for alignment or devices with < 32-bit address width, but then
those are likely to be old and slow anyway.

I'm still a bit worried about the slowness of waiting for an sfbuf if
one is needed, but in practice that might not be a big issue.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20150425/e37d384f/attachment.sig>