From: "Wael Noureddine" <[EMAIL PROTECTED]> Date: Sun, 21 Aug 2005 00:17:17 -0700
> How do you intend on avoiding huge stretch ACKs? The implication is that stretch ACKs are bad, which is wrong. Oh yes, that's right, you're the same person who earlier in this thread tried to teach us that bursty TCPs are non-standard :-) Stretch ACKs are actually a positive thing on a healthy connection and do indeed help the sender. And when loss events occur, LRO stops immediately and delivers the packets as-is so that loss information via ACKs with SACK blocks can immediately make their way to the sender. Linux does actually currently generate stretch ACKs, when beneficial. What happens today, due mostly to interrupt mitigation, is that the stack processes many consequetive packets, and spits out a ton of ACKs one after another. That's actually bad. LRO will cause us to instead do the right thing, which for a healthy connection is to scale the ACK response rate to match the interarrival rate of data. Making the sender process a lot of ACKs is bad, because those are cycles that could be used to do the context switch that gets the sender back onto the cpu to fill the send buffer. What happens right now is that the first ACK wakes up the task, then as we try to schedule the process we're inundated with processing the subsequent data packets and spitting the ACKs out, to the point where it takes longer than necessary to get the process onto the cpu to fill the send buffer. I traced this extensively while working on our TSO implementation. > This is again assuming TOE cannot implement these features. Users should > decide which features they care about, and if TOE doesn't have them then it > won't be a viable alternative for them. You're not going to replicate the entire Linux TCP stack onto your card. TOE is not a viable alternative for anyone who wants to do anything out of the limited scope of features you'll have in your TOE stack. This means if we find an incredible new congestion control algorithm, the TOE setups won't get it. This means if the only way to work around a security hole is to enable some netfilter rule until a better fix exists, user's either stay vulnerable or lose TOE. It's all a lose-lose situation for the user, and we're not going to fall down that slipperly slope if there is anything I can do about it. But we don't need the limitation _at all_ with stateless offload solutions. That's our _whole point_. Why do X with limitations if we don't need do? But I'm personally sick of talking about why TOE is so bad, and I'm going to ignore those parts of this thread in the future, and instead I'm going to participate in the discussions that will actually go somewhere. Those are the ones about getting a good LRO implementation going and into the Linux networking stack. - 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
