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 <[EMAIL PROTECTED]> -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
