From: "Wael Noureddine" <[EMAIL PROTECTED]> Date: Thu, 18 Aug 2005 20:50:17 -0700
> Can you explain why TOE is a hack while stateless offload is not? No knowledge of TCP internals necessary, that defines a clean and maintainable barrier between the device and the network stack. It also allows all of the network stack features to be enabled, even when offloading is being performed. > It is actually surprising that few seem to be concerned with what LSO > and LRO do to TCP. Don't they both change the dynamics of TCP in non- > standard ways? Doesn't this go against Linux's tradition of being the > most RFC compliant of all stacks? LSO, for one, breaks TCP's clock, > increases the sender's burstiness, disrupts congestion control, and > only works in a lossless environment. Has anyone studied the impact > of LSO on network congestion? Who has sanctioned its widespread use? The loss issue is a bug in our implementation, not a limitation of LSO in any way, shape, or form. It will be fixed. Thanks, but no thanks, for the strawman. LSO is fully RFC compliant, and the necessity of that is why I fixed our implementation to correctly follow the congestion window rules. The is no RFC violated by being "bursty". Show me the RFC where TCP burstiness is "standardized". This is yet another strawman. All of the TOE folks have a big bee in their bonnets because none of the the networking stack and driver subsystem maintainers see it as a wise thing to put in. If it's come to the point where we're discussing things like LSO standards conformance and other such strawmen as a justification for TOE, then that's really pathetic. - 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
