net: tcp: Keep track of recv window size change since last ACK

[rlubos]

Windows TCP stack has a peculiar behavior - when running iperf, it will fill out the RX window almost entirely, but will not set PSH flag on packets. In result, our stack would delay the ACK and thus window update, affecting throughputs heavily.

In order to avoid that, keep track of the most recent window size reported to the peer, and reduce it when receiving new data. In case the RX window, as seen from the peer perspective, drops below certain threshold, and the real RX window is currently empty, send an ACK immediately when updating window, so that peer can continue with sending data.

[decsny]

brings RT1060 download from windows up to 71 Mbps, not all the way back to what it was but at least 7/8 of the way back

[jacob-wienecke-nxp]

Testing with this commit, performance out of the box on mimxrt1170-evk is worse than without the delay ack commit.

On main without delay ack commit I am seeing an average around 75Mbps

On main with the commit that is keeping track of recv window size change since last ACK I am seeing an average closer to 50Mbps

A better apples-to-apples comparison on this device is to move all code to ITCM.

On main without delay ack commit and ALL code in ITCM I am seeing an average around 85Mbps

On main with the commit that is keeping track of recv window size change since last ACK and ALL code in ITCM I am seeing an average around 89Mbps.

With the test of all code in ITCM, this new commit performs slightly better than main without the delay ack commit.

EDIT: I should mention that this is on my windows machine.