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: Re: Avoiding memcpy in ethernet drivers


Tarmo Kuuse wrote:
Edgar Grimberg wrote:
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?
For my case, I have one ring of buffers for each send and receive. I
would like to craft the driver as such to point the buffers to the
buffer in sg_list, but I can set up the rings only when the device is
stopped. This excludes ad-hoc setting when receiving/sending.
My idea was to create the sg_list-s (one for send and one for receive)
so they can be available to the init function from the NETDEVTAB_ENTRY
macro. In this way, a driver will need to take care of the pointers
to/from the sg_list-s.
Any comments/advices on this ?

Just pointing out that some ethernet HW requires aligned buffers. E.g. FEC in newer ColdFire devices needs data to be aligned to 4 bytes.


Thanks for pointing that out. I'd say to align them at cache line, this will make it easier to debug in case there are some problems with caches and manual flushing and invalidation is needed. For my driver (eTSEC), the requirements are a bit unbalanced:
"Receive buffer pointer, written by the user. The receive buffer pointer, which always points to the first location of the associated data buffer, must be 8-byte aligned. The buffer must reside in memory external to the eTSEC."
and
"The transmit buffer pointer contains the address of the associated data buffer. There are no alignment requirements for this address."


On the subject, I've read the hardware independent ethernet code, and there is just pointer manipulation happening for sg lists. I guess the matching must be between the a higher level buffer (in the tcp/ip stack, I think) and the hardware dependent ethernet driver. This will break the independence of the low level driver from the stack implementation, I'm afraid. Any other ideas to get rid of the memcpy ?

Regards,
Edgar


--
Kind regards,
Tarmo Kuuse




--
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]