[vortex-bug] Tx int. mitigation

[Donald Becker]

On Fri, 15 Dec 2000, Bogdan Costescu wrote:

> > At 100Mbps the packets have actually been transmitted, and the transmitter
> > is now idle.  Yet the skbuffs are locked and charged against the socket's
> > memory allocation so it won't try to transmit again.  (Again, an
> > oversimplification, but a good mental model.)
> 
> That's something new for me! IOW, the upper levels have 2 indicators about
> transmission: tbusy and the skbuffs themselves. In this case, you're
> right, nothing else can be done...

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 upper layers on older kernels will occasionally call start xmit with
> > dev->tbusy set.  But this only happens with packet retransmissions, not with
> > normal-path packets.  Retransmissions occur on the order of seconds or even
> > minutes, not microseconds.
> 
> I beg to disagree! The first (code) line of start_xmit() is:
> 	if (test_and_set_bit(0, (void*)&dev->tbusy) != 0)
> If I understood it right, test_and_set_bit() returns the value found in
> tbusy before setting it. If it's set, the check for Tx timeout is made; as
> we get Tx timeout reports, it means that on actual kernels (2.2),
> start_xmit() can be called with tbusy set! So it's not a question of
> "older kernels".
>
> Even more, TX_TIMEOUT is set at 400*HZ/1000 (or 2*HZ in your drivers)
> which means sub-second/2 seconds interval. If the upper levels would call
> the function more rarely in the retransmission case, there would be no
> need for such a short interval check in the driver. The way I understood
> this check is that the upper levels _will_ call start_xmit() quite often
> (HZ granularity) and if tbusy is set for enough time, tx_timeout() should
> be called.

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.


Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993