current meaning of BUS_DMA_COHERENT

[Warner Losh]

> On Mar 20, 2015, at 7:31 PM, John Wehle <john at feith.com> wrote:
> 
> On Mar 20, 2015, at 8:27 AM, Ian Lepore <ian at freebsd.org> wrote:
>> The main problem is shared concurrent-access memory, such as buffer
>> descriptor rings which are accessed simultaneously by the cpu and
>> network hardware.  (The same thing happens with other hardware, but NICs
>> are the prime example of it.)
>> ...
>> What we really need is a new type of busdma memory (BUS_DMA_DESCRIPTOR)
>> and a special sync call to use in conjunction with it that takes an
>> offset and length, and the sync is a single operation, no pre/post
>> stuff.
> 
> If you have descriptor A being modified by the device at the same time
> descriptor B is modified by the CPU and they are in the same cache line
> you'll still have problems even with a sync call which takes an offset
> and length.
> 
> Doesn't being able to sync individual descriptors also require padding the
> descriptor size so it's a multiple of the cache line size?

Only if you access them as coherent, cached memory. If you access them
as uncached memory, you don’t need to worry.

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20150321/2cda7618/attachment.sig>