[vortex-bug] Tx int. mitigation

[Bogdan Costescu]

On Fri, 15 Dec 2000, Donald Becker wrote:

> The queue layer, right above the driver, cares only about dev->tbusy.
>
> The protocol level cares about flow control and retransmission.  It doesn't
> care if the transmitter is currently busy.  It cares that it doesn't
> double up by retransmitting data that it knows is already in the local Tx
> queue.
> ...
> The retransmission retry even while dev->tbusy is set is unpredictable.  It
> may occur within microseconds, or it may take 20 seconds.  We don't want to
> falsely declare a Tx timeout on a working link, thus the minimum time check.
> Using tx-while-tbusy is an unreliable mechanism for anything but failure
> recovery.

Things start to make sense now. It means that any driver that is not
written very similar to the skeleton that you designed is not quite
correct: the skbuffs have to be freed as soon as possible, which means
either in start_xmit() or in interrupts generated by the download to the
card. However, the driver that 3Com released is using a scavenger method
very similar to what I was proposing, by programming the hardware timer to
generate interrupts where the check for transmitted skbuffs is done;
still, their driver _is_ working, which means that the upper layers are
more or less "tolerant" to this kind of behaviour. How would you explain
this ?

All ears,

Bogdan Costescu

IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De