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

From: Manfred Spraul (manfred@colorfullife.com)
Date: Sat Dec 28 2002 - 12:54:49 EST


James Bottomley wrote:

>manfred@colorfullife.com said:
>
>
>>Your new documentation disagrees with the current implementation, and
>>that is just wrong.
>>
>>
>
>I don't agree that protecting users from cache line overlap misuse is current
>implementation. It's certainly not on parisc which was the non-coherent
>platform I chose to model this with, which platforms do it now for the pci_
>API?
>
>
You are aware that "users" is not one or two drivers that noone uses,
it's the whole networking stack.
What do you propose to fix sendfile() and networking with small network
packets [e.g. two 64 byte packets within a 128 byte cache line]?

One platforms that handles it is Miles Bader's memcopy based
dma_map_single() implementation.
http://marc.theaimsgroup.com/?l=linux-kernel&m=103907087825616&w=2

And obviously i386, i.e. all archs with empty dma_map_single() functions.

I see three options:
- modify the networking core, and enforce that a cache line is never
shared between users for such archs. Big change. Often not necessary -
some nics must double buffer internally anyway.
- modify every driver that doesn't do double buffering, and enable
double buffering on the affected archs. Even larger change.
- do the double buffering in dma_map_single() & co.

One problem for double buffering in dma_map_single() is that it would
double buffer too often: for example, the start of the rx buffers is
usually misaligned by the driver, to ensure that the IP headers are
aligned. The rest of the cacheline is unused, but it's not possible to
give that information to dma_map_single().

--
    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:12 EST