[ECOS] Re: Avoiding memcpy in ethernet drivers

[Grant Edwards <grante at visi dot com>]

On 2009-03-03, Bart Veer <bartv@ecoscentric.com> wrote:
>>>>>> "Edgar" == Edgar Grimberg <edgar.grimberg@gmail.com> writes:
>
>> Having to write a driver for an ethernet device, I noticed
>> that there are 2 memcpy()s in most of the drivers, one when
>> sending and one when receiving. This usually happens from and
>> to the sg_list passed from the hardware independent ethernet
>> driver. Now, is this really necessary?
>
> Ethernet hardware varies widely, but there are two main
> categories: fifo vs. DMA.
[...]
> With DMA, ideally there would be no need for a copy operation
> - if the hardware was designed just right, and if higher-level
> code like the BSD, RedBoot or LWIP TCP/IP stacks did the right
> thing. Unfortunately neither assumption is safe.
>
> For outgoing packets the DMA engine typically imposes some
> limitations. For example the start of a DMA buffer may have to
> be aligned to an integer boundary, or to a cacheline boundary
> (typically but not always 16-bytes). If an outgoing packet is
> split over multiple buffers then the DMA engine may require
> that every buffer except the last one is a multiple of the
> cacheline size.

My experience is somewhat limited, but I've yet to see a uC
Ethernet controller with a DMA engine that supported splitting
frames in any manner at all (inbound or outbound).  If the
network stack requires that packets be split into various
chunks, then there's simply no avoiding the copy operation.

I think some high-end PCI Ethernet controllers aimed at the
"server" market do have support for scatter/gather DMA, but
that's not really the market for which eCos is intended.

-- 
Grant Edwards                   grante             Yow! HELLO KITTY gang
                                  at               terrorizes town, family
                               visi.com            STICKERED to death!


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss