[tulip] Tx stats invalid if Tx intr on completion not set?

[Donald Becker]

On Thu, 28 Mar 2002, Bhavesh P. Davda wrote:

> What happens if all transmit descriptors currently queued for the 21143
> don't have the TDES1<31> bit set for interrupt on completion?

The interrupt handler isn't called.

The Tulip driver uses this logic to reduce the number of Tx-done
interrupts.
	if (q_used_cnt < TX_QUEUE_LEN/2) {/* Typical path */
		flag = 0x60000000; /* No interrupt */
	} else if (q_used_cnt == TX_QUEUE_LEN/2) {
		flag = 0xe0000000; /* Tx-done intr. */
	} else if (q_used_cnt < TX_QUEUE_LEN) {
		flag = 0x60000000; /* No Tx-done intr. */
	} else {
		tp->tx_full = 1;
		flag = 0xe0000000; /* Tx-done intr. */
	}
	if (entry == TX_RING_SIZE-1)
		flag = 0xe0000000 | DESC_RING_WRAP;

The last insures that we always raise an interrupt on a ring wrap.  This
eliminates the chance that a timed transmit pattern will fill the Tx
ring and stop the transmitter until the TxNoBuf interrupt is handled.

> The HRM seems to indicate that in that case CSR5 won't have TxIntr set.
> Then, how does the tulip driver know about completion of these
> transmitted frames? i.e. how does it update tx_packets and tx_bytes
> correctly?

It's pretty easy to read the code to find this:

	if (csr5 & (TxNoBuf | TxDied | TxIntr)) {

When the Tulip runs out of packets to transmit it will immediately raise
an interrupt.  Handling this interrupt insures that the statistics will
be accurate when the transmitter is idle, and lag only slightly (due to
interrupt mitigation) when the transmitter is active.

Some of my other drivers unconditionally scavenge the Tx queue entries
on any type of interrupt.  This approach to TxDone interrupt
minimization works well because few protocols continuously transmit
without receiving any packets.  But I never rely entirely on this
approach -- the driver should not allow a skbuff to remain on the
trasnmit queue long after it has been actually transmitted.  The obvious
bad case is sending ARP packets without getting a response.  The ARP
code wants its skbuff back in order to try again!

-- 
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