[Top] [All Lists]

Re: Tx queueing

To: Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx>
Subject: Re: Tx queueing
From: Donald Becker <becker@xxxxxxxxx>
Date: Fri, 19 May 2000 22:35:57 -0400 (EDT)
Cc: Andrew Morton <andrewm@xxxxxxxxxx>, "netdev@xxxxxxxxxxx" <netdev@xxxxxxxxxxx>
In-reply-to: <3925A0F3.D3184229@xxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
On Fri, 19 May 2000, Jeff Garzik 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...
> 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.

The drivers still "exist", even if your copy has been updated.  We are not
claiming that bad code can't be changed, just that it was bad code
that replacing good.

> The only exceptions are
> going to be older NICs which only support a single Tx packet buffer
> (3c501 is like this?).

The 3c501 is never ready to transmit again.
It's rarely even ready to receive.
A better approach for primative hardware is for the driver to keep its own
Tx queue of a few packets ready to transmit.  But very few devices need

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

The interface shouldn't have been changed without first testing if it could
be implemented correctly.  Merely guessing that design is reasonable isn't
the same as demonstrating that it works.

The drivers have been able to be mostly backwards compatible for a long time.
That demonstrates that the original interface was reasonable.  It should
also create a minimum requirement for interface changes: "you must be *this*
much better to justify a change".

I'm not averse to having drivers depend on new interface features, when the
new features have offered significant benefits.  An obvious case is
using skb_reserve() to improve cache performance.  The eepro100 driver would
require a new structure if it couldn't use skb_reserve(), and thus it is not
backwards compatible to old kernels.

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

Intel is much more open with documentation than it used to be, but it's
still not easy.
Getting the first i82557 documentation took six months to negotiate a NDA
that would allow releasing the driver.  I've visited Intel in Portland three
times on my own $$.  I though that I would get the i82559 docs when I met
with them in November, but it didn't happen.

I visited the Intel people in Santa Clara earlier this month: they are much
more open, but they develop things based on the 21*4* network hardware, not
the i8255* chips.

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

Donald Becker                           becker@xxxxxxxxx
Scyld Computing Corporation
410 Severn Ave. Suite 210
Annapolis MD 21403

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