David S. Miller wrote:

Becuase we disable TSO on any packet loss whatsoever, we can predict
exactly what the CWND will be at the time a packet is sent.

I've been quiet the past few days, but this is the kind of implementation
I've been thinking of.

When we take away that invariant, which we do want to do, we'll need
to tweak how this works.

Having thought about the topic a bit, it now seems that there were two benchmark 
run-rule compliance problems with TSO in 2.6.  One is the slow-start stuff that 
has been worked-on and may get a couple additional tweaks (hopefully).

The other relates to the business of disabling TSO on a connection upon packet loss.

While the benchmark(s) that spring to mind are run over generally lossless LANs, 
the intent is that the solution be suitable for an Internet connected system 
(yes, someone could probably punch big gaping holes there...).  Internet 
connected systems experience non-trivial packet loss rates and so if TSO 
disabled upon packet loss it means a given benchmark result using TSO deviates 
even more from reality than one without TSO.

I suspect it would be found to be a benchmark special and disallowed.

I do not know what other stacks do with their TSO implementation to know if they 
are in a similar state.  It would be good to know if anyone out there knows and 
would be willing to say.

rick jones