[vortex-bug] Tx int. mitigation

[Bogdan Costescu]

On Thu, 14 Dec 2000, Donald Becker wrote:

> > > You should be calculating the Tx gap the other way.

Sorry, I wanted to ask this before, but I forgot... The original question
was about time that downloaded skbuffs can be kept before free-ing. What I
have proposed (full ring, max sized packets, 10 Mbit/s) was to prove that
packets can be kept in the driver's Tx ring for aprox. 20 ms in a normal
situation; why don't the upper levels protest about this ?
However, the more fundamental question is: why the upper levels keep
track of the skbuffs _after_ they were given to the driver ? (pointing to
some code is OK). Your TCP example doesn't hold IMHO: if the TCP layer
doesn't see the ACK soon enough it's its responsability to re-transmit
_the content_ of the skbuffs, not the skbuffs themselves. Basically, the
fact that the driver freed the skbuffs does not mean that they were
succesfully trasmitted and received at the other end, so the upper levels
cannot assume anything.

> > 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.
>
> The above scenario is where the Tx ring is full, and dev->tbusy is set.

Hmm, that means that my ideea of returning immediately to the upper levels
based on tbusy being set is not the best one. So we go back to Giuseppe's
initial proposal...

> Here is the issue: manipulating the timer is very expensive.

It only takes 1 or 2 'out' operations, provided that you keep somewhere in
the driver the current value written in the register that control what
interrupts are generated. This is non-negligible when you use polling mode
(which being memory only is very fast), but I was not proposing to do it
or every packet.

> And waiting until the queue is full to set the timer means that you might
> have 9 already transmitted skbuffs sitting stagnant in the queue preventing
> retransmission.

If you're checking for tbusy at the beginning of start_xmit() and tbusy is
only cleared by the interrupt, then you're right!

> > Exactly, which means that the upper layer will call start_xmit() again and
> > you can free the tail of the queue at that moment.
>
> But the upper layer won't call it with dev->tbusy set.

That's the same statement that you have made in the older thread about
tbusy and tx_full. I don't understand: if you are sure that the upper
levels don't call when tbusy is set, why do you check for it at the
beginning of start_xmit() before returning or calling tx_timeout() ?
I understood that using tbusy as a flag for the upper levels was the
original ideea, but what it is _now_ in the kernel (2.2) ?

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