netdev
[Top] [All Lists]

Re: Tx queueing

To: Andrew Morton <andrewm@xxxxxxxxxx>
Subject: Re: Tx queueing
From: Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx>
Date: Fri, 19 May 2000 16:21:12 -0400
Cc: Donald Becker <becker@xxxxxxxxx>, "netdev@xxxxxxxxxxx" <netdev@xxxxxxxxxxx>
Organization: MandrakeSoft
References: <392407D4.BE586507@xxxxxxxxxx> <Pine.LNX.4.10.10005181222570.1658-100000@xxxxxxxxxxxxx> <392421F1.249E284F@xxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
Andrew Morton wrote:
> Donald Becker wrote:
> > ...
> > >
> > > 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.
> 
> Burn them boats :)
> 
> I've been looking for a compatibility header which maps
> netif_stop_queue() into dev->tbusy manipulation, but I can't find one.
> Have I missed something?

IMNSHO you should try the compatibility module at
http://gtf.org/garzik/drivers/kcompat24/

It provides the necessary glue to port 2.3.x/2.4.0 drivers back to
2.2.x.

Note that its still an early development version, but it is already
being used in a couple places.


> > > 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.
> 
> Does it make that much difference?  When we discussed this starting
> April 24 the consensus seemed to be that the overhead of s/w
> checksumming is in the noise floor when combined with the copy.
> 
> Anyway, I have religious objections to hardware IP checksums.
> 
> I've seen several instances where they would have failed to detect
> errors which software checksumming would detect:
[...]

That's the bugger of the problem.  I take the opposite stance because I
want to fully maximize my hardware's capabilities -- if it can do good
and accurate checksums, then I would certainly prefer to offload that
processing.

But if the network hardware has problems with checksumming, finding the
cause of the problem is often more difficult than normal since it is
easy to blame the other side, or unrelated hardware, for the
checksumming problems.

        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>