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?
> ...
>
> 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!
> > 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:
- cs89x0 with Rx DMA on a too-fast EISA bus was dropping bits when
DMAing into main memory. If the checksum had been calculated on the
NIC, it would have said "OK", while the in-memory packet was corrupted.
- 3c59x bug (I forget what is was, but DMA ponters were getting changed
at the wrong time) causing in-memory corruption. Again, the NIC would
have told us it was OK.
Layer 3 checksums are there to detect layer 3 errors. Ergo, they should
be put at the top of layer 3, not at the top of L2.
--
-akpm-
|