[ECOS] Ok, architecture question time

[Chuck McManis <ecos at mcmanis dot com>]

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