This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Ok, architecture question time
- From: Chuck McManis <ecos at mcmanis dot com>
- To: ECOS Discussion Group <ecos-discuss at sources dot redhat dot com>
- Date: Fri, 17 Feb 2006 00:30:50 -0800
- Subject: [ECOS] Ok, architecture question time
So there is a latent bug sort of in the Rhine driver which involves the key
value sent when sending data. According to the documentation this key is
used by the upper layers to figure out that their packet has successfully
gone on its way.
The driver only keeps one key. Thus it only can have one packet in flight
at any time. Now this isn't a "bug" in the sense the author wrote
can_send() in such a way that it only returns 1 or 0, so even if there are
four open descriptor buffers the driver will only accept one packet. Makes
the system quite a bit slower than it would otherwise be but maintains the
invariant that the ethernet subsystem sets out.
So my architecture question is that the key is used as a means of managing
mbufs right? Basically once you get a success ack with the key associated
with a particular mbuf chain you can throw that chain away, and if you
don't get an success ack you can simply dump the mbuf chain back into the
queue (that about right?) So my driver, which wants to properly tell the
upper level code it can accept a number of packets for queuing needs to
track the key value as well for every transmit packet. Sound about right?
--Chuck
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss