[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