Yunsong (Roamer) Lu writes: > James Carlson wrote: > > LSO looks to the rest of the software like a middlebox in the network, > > and that buys with it all of the technology change problems as we've > > had in the past. Every time you make a transport change, you've got > > to modify that middlebox to do something appropriate with that > > transport bit, and that costs extra. Or you end up with "orphan" > > protocols (like IPsec, SCTP, or IPv6) that just aren't supported and > > always run in the slow path. Both answers are bad. > Not really. > LSO only happen on the tx server, and it's invisible to any other > network parts. For the host, it's easy to decide whether to do LSO for > the next transmission according to the current state of transport. It's > actually "part" of transport protocol, but not a "middlebox" somewhere.
It's "invisible" to the other network parts in exactly the same way that a middlebox is. It plays the same role. It's a middlebox in networking terms because it's generating transport layer headers on its own even though it does *not* have direct access to the actual transport layer state. > Look at hardware checksum offloading. It didn't start with wide coverage > as it does today, but it has been proved very helpful to the > performance. Even today, you have to disable some type of hardware > checksum offloading when IPSec is present. Should we discuss whether to > keep the hardware checksum offloading support in Solaris stack? Perhaps, though that's a different discussion. This is about LSO, which has the IP layer lying to the transport layer about the MTU in use, and has the driver segmenting the message and conjuring up new transport layer headers. > By the way, LSO has its targeting area, and it's won full-TOE because of > its simpleness for both software and hardware supports. The debate between the end-to-end and the hardware-acceleration arguments is much older than that. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
