This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Ok, architecture question time
- From: Gary Thomas <gary at mlbassoc dot com>
- To: Chuck McManis <ecos at mcmanis dot com>
- Cc: ECOS Discussion Group <ecos-discuss at sources dot redhat dot com>
- Date: Fri, 17 Feb 2006 01:44:00 -0700
- Subject: Re: [ECOS] Ok, architecture question time
- References: <6.1.2.0.2.20060217001744.04c71bd8@66.125.189.29>
On Fri, 2006-02-17 at 00:30 -0800, Chuck McManis wrote:
> 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?
>
Correct. The idea is that the 'key' can be used to keep track of
packets that are "in flight". Once they have been processed, the upper
layers can move on (the memory associated with that packet can be
released). If your driver can handle more than one packet being ready
to go out (any device that is not programmed I/O should be able to),
then have "XXX_can_send()" return the number which are possible and the
upper level driver will attempt to queue them up. This allows for a
couple of possibilities - zero data copies in the hardware driver and
back to back packets going out.
> --Chuck
>
>
--
Gary Thomas <gary@mlbassoc.com>
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss