netdev
[Top] [All Lists]

Re: Tx queueing

To: Andrew Morton <andrewm@xxxxxxxxxx>
Subject: Re: Tx queueing
From: Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx>
Date: Sat, 20 May 2000 14:38:38 -0400
Cc: Donald Becker <becker@xxxxxxxxx>, "netdev@xxxxxxxxxxx" <netdev@xxxxxxxxxxx>
Organization: MandrakeSoft
References: <Pine.LNX.4.10.10005181222570.1658-100000@xxxxxxxxxxxxx> <3925A0F3.D3184229@xxxxxxxxxxxxxxxx> <39262875.B380A44E@xxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
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)


> 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?

If a 2.3.x driver is proven stable and superior, people will naturally
want to backport it.  Heck people are still downloading Donald's latest
stuff and trying to stuff it into their 2.0.x kernel.  I'm not bending
over backwards for 2.2.x compatibility, but I recognize that some people
want to do so.


> 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.

FWIW I am not doing that for the corresponding drivers I maintain in
2.3.x.  Anybody who reports a problem for 2.2.x rtl8139 or tulip will
probably get a response, but not a patch unless things are really
critical [and one of Donald's drivers doesn't already solve the
problem].

There are a lot of changes in 2.3.x, and work yet to done, so my hands
are full there...


> Which drivers are using kcompat24?

AFAIK, right now 8139too and i810_rng work with it, and emu10k1 (SB Live
sound driver) uses a modified version of kcompat24 (see
2.2/emu_wrapper.*)

        Jeff


-- 
Jeff Garzik              | Liberty is always dangerous, but
Building 1024            | it is the safest thing we have.
MandrakeSoft, Inc.       |      -- Harry Emerson Fosdick

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