netdev
[Top] [All Lists]

Re: Tx queueing

To: Andrew Morton <andrewm@xxxxxxxxxx>
Subject: Re: Tx queueing
From: Donald Becker <becker@xxxxxxxxx>
Date: Thu, 18 May 2000 14:08:20 -0400 (EDT)
Cc: "netdev@xxxxxxxxxxx" <netdev@xxxxxxxxxxx>
In-reply-to: <392421F1.249E284F@uow.edu.au>
Sender: owner-netdev@xxxxxxxxxxx
On Fri, 19 May 2000, Andrew Morton wrote:

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

David Hinds has compatibility macros.  But he can be more pragmatic about
the network drivers than I am.  It only has to work well enough for his PC
Card system, it doesn't have to be The Right Thing.

> > Perhaps all on that IRQ.  But you didn't really need to service the SCSI
> > controller or the other network interfaces, did you?
> 
> :)  Think of the cache impact!

And those damn user programs are always flushing *my* cache lines.  We
should just kill them off so that the network drivers can operate unmolested. 

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

Tx checksumming vs. Rx checksumming.
Checksumming is almost free if you are in the midst of doing the copying
anyway.
If you Rx checksum on one processor, and use the data on another processor,
it is astonishingly costly.

> Anyway, I have religious objections to hardware IP checksums.

As do I, as I have stated in years past, but...

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



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