Re: Avoiding memcpy in ethernet drivers

On 2009-03-03, Bart Veer <bartv <at> ecoscentric.com> wrote:
>>>>>> "Edgar" == Edgar Grimberg <edgar.grimberg <at> 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.