The code can potentially get really messy and ugly if we start
preemptively building larger frames "hoping" the cwnd will be
large enough by the time we push it onto the wire.  Segmenting
at send time is completely upside down to the way packets are
built currently for transmission.  A bad guess also means that
we'll spend significant cycles chopping up TSO packets and
resegmenting the queue.

Just some pseudo-random thoughts which may or may not hold true in the context 
of Linux TSO, and may or may not show my utter ignorance of current cwnd 
behaviour :)

*) At present the code executed at time of user send knows about the cwnd at the 
time of user send.  It then builds some number of TSO-sized segements and queues 
them

*) "Classic" cwnd behaviour is either:

    a) Increasing rapidly to ssthresh
    b) Increasing slowly after ssthresh
    c) Restarting from initial values after timeout

(IIRC there is other cwnd manipulation for fast rtxes and the like)

*) If there is a timeout, any previously queued TSO-sized segments are going to 
have to be resegmented anyway no matter what their size was before the timeout. 
So conservative versus optimistic guesses there would not seem to matter.

*) If there is a fast rtx and the like, any previously queued TSO-sized segments 
may very likely (not certain though) have to be resegmented, particularly if 
they were queued when cwnd was >= ssthresh

*) If cwnd is < ssthresh, the next cwnd is going to be > current cwnd unless 
there is a retransmission of some sort.

*) If cwnd is >= ssthresh, cwnd will remain cwnd for some time (compared to 
otherwise)

It would seem that the segmentation code, if it knew ssthresh as well as cwnd 
_could_ make some reasonably optimistic guesses as to cwnd growth while doing 
its segmentation.  Guesses that wouldn't seem to be any worse than they would be 
at present if there is a full RTO at least.  And if the tcp_tso_win_divisor is > 
1, it is possible that even the onesey-twosies of fast rtx may not require all 
_that_ much resegmentation?

of have I just gone-off into the deep-end?

rick jones

BTW, speaking of tcp_tso_win_divisor, I've gone back through my traces and they 
do not support my recollection, so I must have been confused as to what I was 
looking-at when I got that impression.