[vortex-bug] Tx int. mitigation

Bogdan Costescu Bogdan.Costescu@IWR.Uni-Heidelberg.De
Thu, 14 Dec 2000 21:00:19 +0100 (CET)


On Thu, 14 Dec 2000, Donald Becker wrote:

> You should be calculating the Tx gap the other way.
>   It only takes (10 minimum sized packets at 100Mbps) about 100usec to empty
>     the Tx queue.
>   You will wait until the next timer tick to refill.

No! You will see that the Tx ring is full when trying to re-fill from
start_xmit() and go to step 2 of Giuseppe's scheme.
Freeing the Tx ring is done in two places:
- in start_xmit() if a packet comes fast enough
- in ISR if no packet came and the hardware timer expired

>   The reason the Tx queue is full in the first place was that you had lots
>     of packets to be transmitted

Exactly, which means that the upper layer will call start_xmit() again and
you can free the tail of the queue at that moment.

> The scavenge code is the first to know that the queue is non-full or
> empty.  Note that "empty" is too late -- it takes a while to restart and we
> don't want a gap in transmission.

I was calling "scavenge code" only the part in ISR which cleans the Tx
ring after the hardware timer expires. And for this you only need to do
something like:

lock
int i = vp->dirty_tx % TX_RING_SIZE;
while (1) {
	if (DnComplete bit is not set for packet tx_ring[i]) break;
/* or	if (DownListPtr == tx_ring[i]) break;	*/
	free tx_ring[i];
	i++;
}
vp->dirty_tx = i;
unlock

There is no need to check for cur_tx here; however, if you put the test
for tbusy (step 5) at the very beginning of start_xmit(), you have to
clear tbusy here.

Sincerely,

Bogdan Costescu

IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De