This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Avoiding memcpy in ethernet drivers


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]