On Tuesday 23 August 2005 17:21, David S. Miller wrote: > From: "Leonid Grossman" <[EMAIL PROTECTED]> > Date: Tue, 23 Aug 2005 02:25:07 -0400 > > > On a more serious note, I'm all in for stateless offloads but I think > > that dropping stack support for adapters that don't implement TSO, etc > > (either in hardware or in the driver) is a pretty long shot - someone > > will have to update all the legacy drivers out there. > > We're not dropping support, the idea is to have a software > shim that does the offload in software if the hardware isn't > doing it. > > This will actually decrease TCP stack processing at the cost > of some minimal work in the software shim. And, as a result, > we can remove all of the "if (device supports TSO)" checks > all over the place in the TCP stack, we can just assume the > facility is available all the time.
Hmm - one problem is that you would lose copy checksum on NICs that don't do hardware checksumming because if you handle multiple packet as a big piece there is no easy way to reconstruct the individual MSS sized checksums (or at least not without a lot of the overhead individual packet processing has) Doing the additional checksums could be quite expensive and would cost Linux one advantage over BSD stacks :) On the other hand it might make sense to do this even on hardware that doesn't support TSO - many card designs can submit a list of packets more efficiently than each packet at a time. If anything the cost of taking the driver lock will be lower. The trick would be to design the software shim in a way that such optimizations are easily possible, e.g. by separating the code to add headers/compute checksums However the drawback is that you would likely need to submit the packets as two pieces (payload and header) which would need more accesses to TX rings and could slow down the hardware. I'm not sure the whole software shim scheme is a good idea. It has too many drawbacks. -Andi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
