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]

Re: DMA capable Ethernet driver... (zero-copy)?


Nick Garnett wrote:
Lars Povlsen <lpovlsen@vitesse.com> writes:

Unless the fragments (notably the first - the ethernet header) are
squirelled away, it will be thrashed randomly by subsequent stack use.

So is this a bug?

Off course, other network stacks may have better characteristics, but
at least redboot will exhibit random data thrashing if I use straight
DMA. The occurrence will be dependent on how fast the DMA is started
(other system/network) activity - which may be non-existing in the
redboot -
which could explain why this apparently is not a problem...?

RedBoot doesn't use interrupts, so eth_drv_write() is synchronous. The implementation of eth_drv_write() used by the RedBoot stack polls until the packet has been sent. The send() routine is called, then the driver's poll() routine is called repeatedly until the tx_done() routine is called, then eth_drv_write() returns.

The ethernet drivers are only asynchronous when interrupts are
available, and only the BSD and LwIP stacks are able to take advantage
of that since they run with the kernel enabled.

Ahhh, I did'nt realize it was eth_drv_write() itself poll()'ing - so no stack unwind until done. That explains everything.

So I will pretend like I never read the "At this point, you should move the data to some âsafeâ location before returning" comment... False alarm, it seems!

Thanks again,

---Lars


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