netdev
[Top] [All Lists]

Re: Tx queueing

To: Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx>
Subject: Re: Tx queueing
From: Andrew Morton <andrewm@xxxxxxxxxx>
Date: Sat, 20 May 2000 15:53:57 +1000
Cc: Donald Becker <becker@xxxxxxxxx>, "netdev@xxxxxxxxxxx" <netdev@xxxxxxxxxxx>
References: <Pine.LNX.4.10.10005181222570.1658-100000@vaio.greennet> <3925A0F3.D3184229@mandrakesoft.com>
Sender: owner-netdev@xxxxxxxxxxx
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.


Do we really think it's worth preserving the compatibility?  I mean, the
2.3 series is where we place actual algorithmic enhancements, but doing
this in 2.2 is politically incorrect - 2.2 is supposed to be bugfixes
only (I think).  So they diverge __by design__.  If you want to put some
nifty new feature into your 2.3 driver and it's also a 2.2 driver then
you have a problem?

This approach places the onus on maintainers to be familiar with both
series, and to concientiously feed bugfixes back to 2.2 (and watch Alan
fumble them :)), but that's not too hard.

Which drivers are using kcompat24?

-- 
-akpm-

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