This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Avoiding memcpy in ethernet drivers
- From: Edgar Grimberg <edgar dot grimberg at zylin dot com>
- To: Bart Veer <bartv at ecoscentric dot com>
- Cc: Edgar Grimberg <edgar dot grimberg at gmail dot com>, ecos-discuss at ecos dot sourceware dot org
- Date: Wed, 04 Mar 2009 09:38:13 +0100
- Subject: Re: [ECOS] Avoiding memcpy in ethernet drivers
- References: <d0f570ed0902271243m4825b18bq636d5f2e98676583@mail.gmail.com> <pnr61eh3es.fsf@delenn.bartv.net>
- Reply-to: edgar dot grimberg at zylin dot com
Hi Bart,
Thanks for the response. The reason why I started the conversation is
that I did a bit of profiling on the working system and memcpy is on the
top of the list. I was expecting this and, in order to optimize, I
wanted to do something about the biggest CPU consumer. In other systems
I would have been linking the code into a faster RAM area, but in this
case I have none available. So my next idea was to minimize the usage of
memcpy.
Some comments inlined:
Edgar> Having to write a driver for an ethernet device, I noticed
Edgar> that there are 2 memcpy()s in most of the drivers, one when
Edgar> sending and one when receiving. This usually happens from
Edgar> and to the sg_list passed from the hardware independent
Edgar> ethernet driver. Now, is this really necessary?
Ethernet hardware varies widely, but there are two main categories:
fifo vs. DMA.
My case is, of course, DMA based ethernet.
Changing the current API between drivers and higher-level code would
impact existing drivers. There are a number of different ways of
tackling that problem, but nothing simple.
This is what I'm afraid of. I tried to hack my way around it for a short
while, but I don't see an easy way to do it without breaking the
existing code and to keep the drivers independent from the stack
implementation.
The current code works well enough for most people. Realistically, it
is unlikely that anything would happen in this area except possibly as
part of a re-import of the BSD stack. Just the re-import would be a
big job, never mind changing the device driver interface. It may
happen some day, most likely if/when somebody really needs maximum
performance and is willing to pay for the work.
In my case, the clients are spinning their own tcp/ip stack with zero
memcpy and some FPGA help. I just wanted to provide a "reference" system
for measurements, the fastest one I can get with minimal modifications.
Regards,
Edgar
--
Edgar Grimberg
System Developer
Zylin AS
Phone: (+47) 51 63 25 00
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss