This is the mail archive of the ecos-devel@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] |
"Lars Povlsen" <lpovlsen@vitesse.com> writes:
Hello!
On working on a.k.a. Ethernet for eCos I was initially triggered by seeing a stack-allocated Ethernet header (redboot/stand-alone) to investigate other Ethernet drivers... I was sad to see only copying send() implementations until I saw the following comment in the eCos docs:
"Note: In future, this function may be extended so that the data need not be copied by having the function return a "disposition" code (done, send pending, etc). At this point, you should move the data to some "safe" location before returning."
Is this really the state of affairs? Copy no matter that the hardware may have all kinds of fancy scatter/gather frame DMA?
Direct DMA from the buffers should work since they should not be released until the driver calls the tx_done() function. A key is passed back and forth so that the calls can be properly matched. As an example the Intel 82544 driver does direct DMA transmission.
I have to admit that I'm not entirely sure what that note means, since the functionality it describes is already mostly present in the send()/tx_done() interface. Perhaps Gary, who probably wrote it several years ago, could explain what he meant.
The comment was mostly an indication of what the hardware driver *could* do. As Nick said, the framework is in place to let the driver do whatever it wants with the data. If you want to use zero-copy and your hardware can handle it, the 'key' with callback mechanism allows for the data buffers to be held (not reused) by the stacks until the transmission is complete. Achieving zero copy on input is a bit trickier and the framework doesn't quite cut it - there would need to be a way to create incoming buffers before hand that the driver could be instructed to use and the receive callback would then just indicate that the data had arrived. At this time though, the middle layer (eth_drv.c and friends) does not support this.
-- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |