netdev
[Top] [All Lists]

Re: Tx queueing

To: Donald Becker <becker@xxxxxxxxx>
Subject: Re: Tx queueing
From: Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx>
Date: Fri, 19 May 2000 16:15:47 -0400
Cc: Andrew Morton <andrewm@xxxxxxxxxx>, "netdev@xxxxxxxxxxx" <netdev@xxxxxxxxxxx>
Organization: MandrakeSoft
References: <Pine.LNX.4.10.10005181222570.1658-100000@xxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
Donald Becker wrote:
> 
> On Fri, 19 May 2000, Andrew Morton wrote:
> 
> > A number of drivers do this:
> >
> > start_xmit()
> > {
> >       netif_stop_queue()
> >       ...
> >       if (room for another packet)
> >               netif_wake_queue()
> >       ...
> > }
> >
> > I suspect this is a simple port from the dev->tbusy days.

Not only is it simple, it's wrong wrong wrong.  The only exceptions are
going to be older NICs which only support a single Tx packet buffer
(3c501 is like this?).

Andrew (or anyone else) -- do you know any of existing drivers which use
this broken logic?

That logic was used in a few of my softnet conversions, but was quickly
replaced with bug free and more correct code.


> Yes, it's likely from a blind search-and-substitute.
> Using stop_queue() and wake_queue() in the transmit path is part of the
> reason why the 2.3 changes are bogus.
> It is not possible, with these semantics, to write a driver that works well
> in both pre-2.3 and 2.3.

Since the example logic above is wrong that's not surprising :)

There should not be a problem creating drivers for both 2.2 and 2.3 once
broken code such as the above is corrected.


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


> > Has anyone done any serious work with NIC/CPU bonding?
> 
> The Mindcraft "benchmark" is superficially obvious, but the big network
> difference was that they were apparently using the TCP/IP checksum hardware
> on the i82559.  This has far more effect on SMP performance than anything
> else that was done.  We didn't even find out that the chip had the feature
> until months later, and still don't have the documentation on how to use
> it.

Has anyone tried to get NDA'd doc from Intel?  Andrey?  Donald?

Some companies are reluctant to give out databooks, but in my experience
very few of those companies are in turn reluctant to give out reference
source code and databooks under an NDA which allows for open source
development.

Regards,

        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>