David Laight wrote:
> Manuel Bouyer <bouyer@antioche.eu.org>  wrote:
>> At last the "transmit underflow" is that the tulip chip couldn't read data
>> fast enouth from the host memory: to minimize latency, ethernet chips start
>> transmitting on the wire before they have read the full packet from host
>> memory. Now, if they can't read data fast enouth, they have to stop
>> transmitting, which means that the packet is lost. It doens't have anything
>> to do with interrupts, it's a pure PCI issue.
> 
> That is the most stupid 'feature' ever invented [1], I'm not sure whether
> netbsd's drivers use it - I've never done so, such features often increase
> the cpu load and interrupt load so are a net loss.

If it is done right, the idea is to reduce packet latency & RTT's, although it 
buys you more on slow links, and less on faster ones.

A proper implementation of this feature involves a backout if a transmit 
underflow is seen-- by waiting for more bytes to show up before starting to 
send the packet-- and eventually switching to "store and forward" mode after 
three or four underruns are seen.

On the other hand, if you don't like the idea, then you can probably force the 
driver to work in store and forward mode all of the time if you prefer.

-- 
-Chuck