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

From: Manfred Spraul (manfred@colorfullife.com)
Date: Fri Dec 27 2002 - 19:20:25 EST


James Bottomley wrote:

>>Noone obeys that rule, and it's not trivial to fix it.
>>
>>
>
>Any driver that disobeys this rule today with the pci_ API is prone to cache
>related corruption on non-coherent architectures.
>
>
The networking core disobeys the rule in the sendfile implementation.
Depending on the cacheline size, even small TCP packets might disobey
the rule. The problem is not restricted to drivers.

>
>
>>Is it really impossible to work around that in the platform specific
>>code? In the worst case, the arch code could memcopy to/from a
>>cacheline aligned buffer.
>>
>>
>
>Well, it's not impossible, but I don't believe it can be done efficiently.
>And since it can't be done efficiently, I don't believe it's right to impact
>the drivers that are properly written to take caching effects into account.
>
>Isn't the better solution to let the platform maintainers negotiate with the
>driver maintainers to get those drivers they care about fixed?
>
>
I agree that the performance will be bad, but like misaligned memory
access, the arch code should support it. Leave the warning about bad
performance in the documentation, and modify the drivers where it
actually matters.
Your new documentation disagrees with the current implementation, and
that is just wrong.
And in the case of networking, someone must do the double buffering.
Doing it within dma_map_single() would avoid modifying every pci driver.

--
    Manfred

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Tue Dec 31 2002 - 22:00:11 EST