EEPro100 change to Tx Threshold code

[Donald Becker]

On Mon, 29 Mar 1999, Michael Barthelow wrote:

> Subject: RE: eepro100.c: configuration bug
> 
> > There shouldn't be collisions with a FDX connection -- I 
> > assume you mean CRC errors in that case.
> 
> I meant frame alignment errors, which I think could happen as the result of
> an interrupted (truncated) transmit.

OK.
Although this wasn't really a bug, it prompted me to look at what I was
doing about the transmit threshold setting on the eepro100 driver.

It turns out that I had allowed setting the two other Tx threshold values
(FIFO and FIFO burst count), but had a fixed Tx threshold of 256 bytes.

Don't confuse this with the Tx FIFO threshold, which sets when the FIFO is
refilled, but rather the "don't start sending until you have this many bytes
in the FIFO" setting.  A subtle difference.

So I put dynamic Tx threshold code into the driver.
v1.07
  ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/test/eepro100.c
Please send a report if you try it out.

Note that, like my other drivers, it's "one way": the threshold value will
only increase.  It has a starting value of 256 bytes, which is bumped up in
32 byte increments to a maximum of 1920 bytes.  (Of course it can never
grow over 1514 bytes.)

Starting at a lower value or slowly dropping the threshold over time could
be trivially implemented, but I'm opposed to knowingly sending out corrupted
packets.

[[ Note: I've implemented adaptive Tx threshold settings in most other
drivers.  It's never trigged on most machines, but when it is triggered you
usually are doing some heavy-duty work where you care less about latency than
throughput and not corrupting packets. ]]

Donald Becker					  becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center,  Greenbelt, MD.  20771
301-286-0882	     http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html