[vortex-bug] DPD FSH for Cyclone/Tornado

Donald Becker becker@scyld.com
Wed, 17 May 2000 16:33:28 -0400 (EDT)


On Wed, 17 May 2000, Bogdan Costescu wrote:

> I thought that the Alexey's answer was for both, but I might be wrong...
> Anyway, if 2.2 has no xmit_lock (or any other way of locking start_xmit),
> then tbusy should be in fact something like in_start_xmit that would only
> be set at the beginning and cleared at the exit from start_xmit. The
> current code also clears it in vortex_tx_timeout (which might be OK) and
> vortex_interrupt (which might not be OK because it's async WRT
> start_xmit).

That's the point of the tx_full flag in many of the drivers.  See
    ftp://scyld.com/pub/network/pci-skeleton.c

You create a race condition if you clear dev->tbusy when the transmit path
thinks that it is locked against re-entry.

  vp->tx_full == 0  &&  vp->cur_tx - dirty_tx >= TX_QUEUE_LEN
Means that the transmit routine is just now filling the Tx queue.

  vp->tx_full  &&  vp->cur_tx - dirty_tx >= TX_QUEUE_LEN
Means that the transmit routine has filled up.
  
  vp->tx_full  &&  vp->cur_tx - dirty_tx < TX_QUEUE_LEN
Means the transmit queue was full, but is now accepting more entries.
You get much better system performance if you put some hysteresis in the
check e.g.
  vp->tx_full  &&  vp->cur_tx - dirty_tx < TX_QUEUE_LEN - 4
This allows four packets at a time to be queued.

The vortex driver operates differently than many because it has evolved
around the unusual 3Com design.  The 3Com Vortex design was one of the
earliest PCI bus masters, and suffers from several quirks.

> And if the compatibility with older kernels that do not have xmit_lock or
> similar is a concern, would it be feasible to #ifdef usage of tbusy?

Linus will reject anything that smells of backward-compatible support.
The acceptable approach is to write a macro that cleanly encapsulates the
difference, and pass it off as an abstraction layer rather than a
compatibility layer.

Be cautious: design your abstractions, rather than just adding them
ad-hoc. It's far more common to see a bad abstraction layer that hides the 
important functionality in a morass of verbosity, than one that makes the
code clearer.

Donald Becker				becker@scyld.com
Scyld Computing Corporation
410 Severn Ave. Suite 210
Annapolis MD 21403