netdev
[Top] [All Lists]

Re: Tx queueing

To: Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx>
Subject: Re: Tx queueing
From: jamal <hadi@xxxxxxxxxx>
Date: Sat, 20 May 2000 19:49:46 -0400 (EDT)
Cc: Andrew Morton <andrewm@xxxxxxxxxx>, Donald Becker <becker@xxxxxxxxx>, "netdev@xxxxxxxxxxx" <netdev@xxxxxxxxxxx>
In-reply-to: <3926DBAE.92459AD5@mandrakesoft.com>
Sender: owner-netdev@xxxxxxxxxxx
On Sat, 20 May 2000, Jeff Garzik wrote:

> Andrew Morton wrote:
> > 
> > Jeff Garzik wrote:
> > >
> > > > > It would seem to be more sensible to do
> > > > >
> > > > > start_xmit()
> > > > > {
> > > > >       ...
> > > > >       if (!room for another packet)
> > > > >               netif_stop_queue()
> > > > > }
> > > >
> > > > This doesn't give us a way to set dev->tbusy, which is required for all
> > > > pre-2.3 kernels.
> > >
> > > Why not?  Maybe I am missing something.  A 2.2.x implementation of
> > > stop_queue should set dev->tbusy's bit 0.  That's what acenic and my
> > > kcompat software both do.
> > 
> > What I meant was, if the 2.2 driver did this:
> > 
> > start_xmit()
> > {
> >         dev->tbusy = 1;
> >         ...
> > }
> > 
> > and the 2.3 driver does this:
> > 
> > start_xmit()
> > {
> >         netif_stop_queue();
> >         ...
> > }
> > 
> > then the simple #define obviously perserves compatibility.    But once
> > we remove the up-front netif_stop_queue() (which is quite legit because
> > some of the tbusy functionality is handled by dev->xmit_lock in 2.3)
> > then we have nowhere to put the 'tbusy = 1' macro.
> 
> tbusy=1 occurs at device open time, so the logic is preserved.
> 
> For 2.2.x drivers though I don't think start_xmit is serialized (is
> it?), which would imply the need for testing something, or at least
> doing your own serialization via spinlocks.  (2.2.x drivers did a
> test_and_set(&tbusy) IIRC)
> 

dev->xmit_lock in 2.3 serializes the device. Note, 2.3 serializes (per
device) i.e much more SMP fine grained than 2.2 which is
serialized/protected by start/end_bh_atomic()
In a way, nothing to do with tbusy really. Just improvement on
start/end_bh_atomic().

tbusy stands for "transmission is busy". Donald might be able to provide
better history. It was added, in my understanding, to stop the
host processor from overwhelming the already overloaded NIC. In the simple
case, when the DMA ring is filled up. Or that weird card that someone
mentioned as being able to FIFO a single packet.
netif_stop_queue() does the _exact_ tbusy functionality (with additional
removal of old cruft).

Perhaps what Andrew has proposed is more efficient (but breaks backward
compatibility) but to point that the original was totaly wrong has me
scratching my head. Jeff, when you say some modern PCI hardware has
problems with the described semantics: can you provide more details? 

cheers,
jamal



<Prev in Thread] Current Thread [Next in Thread>