Re: [RFT][PATCH] generic device DMA implementation

[Manfred Spraul <manfred@colorfullife.com>]

James Bottomley wrote:

>The problem really only occurs if the CPU can modify part of a cache line 
>while a device has modified memory belonging to another part.  Now a flush 
>from the CPU will destroy the device data (or an invalidate from the driver 
>destroy the CPU's data).  The problem is effectively rendered harmless if only 
>data going in the same direction shares a cache line (even if it is for 
>different devices).  It strikes me that this is probably true for network data 
>and would explain the fact that I haven't seen any obvious network related 
>corruption.
>  
>
Yes. Networking usually generates exclusive cachelines.
I'm aware of two special cases:
If multiple kmalloc buffers fit into one cacheline, then it can happen 
all the time. But the smallest kmalloc buffer is 64 bytes [assuming page 
size > 4096].
Is your cache line >= 128 bytes?

Or sendfile() of a mmap'ed file that is modified by userspace. That is 
the recommended approach for zerocopy tx, but I'm not sure which apps 
actually use that. IIRC DaveM mentioned the approach.

Additionally, the TCP checksum could catch the corruption and resent the 
packet - you wouldn't notice the corruptions, unless you use hw checksums.

--
    Manfred