tcp: allow TSO even while RX path is unordered

[rscheff]

Summary

Over IP networks, forward and return path largely
act independently from each other. Why disable LRO
on the TX side, when reordering/loss is happening
on the RX half-connection.

[tuexen]

Do you mean tcp: allow TSO even while RX path is unordered instead of tcp: allow LRO even while RX path is unordered?

[cc]

Also, please correct the SUMMARY section:

Why disable LRO to Why disable TSO

sys/netinet/tcp_output.c

515–516

I think this check comes from commit b3c0f300fbf1e175fc42b573f3f324a3c6bb85c7.

But I don't know exactly what does SACK advertizements mean, from local or from peer(foreign)?

If it is from local (most likely), can we also remove this SACK advertizements from the comment?

[peter.lei_ieee.org]

sys/netinet/tcp_output.c

559

Removal of the rcv_numsacks check can also be made in the same code for bbr_output_wtime() in bbr.c

sys/netinet/tcp_stacks/rack.c

19933

We can't remove the tp->rcv_numsacks check here (yet) -- rack_fast_output() does not handle adding any SACK blocks, so the code path should fall through to the below in order to properly handle the case where tp->rcv_numsacks may have become non-zero to add them (and discontinue using rack_fast_output while SACK blocks need to be sent)

[rrs]

sys/netinet/tcp_stacks/rack.c

19934

This is a good point Peter, and the fast-path should *not* ever have to add sack-blocks.. it should only be enabled if there are no sack blocks to add.
Note that the fast-path is *only* fast for pacing. In a connection where pacing is not enabled there is about zero benefit from it since it is rarely called (you are busy bursting 40 packets at a time)... Now on the other hand when pacing is enabled it means you gain about 4-5% (at least that is what Drew and I observed back in the day when it was added).

[rscheff]

• address peter's feedback for rack and bbr

[rscheff]

• update comment to reflect current checks in the code