recwin change

[Scheffenegger, Richard]

Hi Jonathan, 

In your larger patch to fix up long int to int32_t 

https://reviews.freebsd.org/rS306769#change-l6GoMSS8L7SS

You seem to have slipped in a functional change for the receive window:


-	recwin = sbspace(&so->so_rcv);
+	recwin = lmin(lmax(sbspace(&so->so_rcv), 0),
+	    (long)TCP_MAXWIN << tp->rcv_scale);

While https://reviews.freebsd.org/D7073
Makes it clear that the lmax(sbspace(&so->so_rcv), 0) is to prevent any potential negative value to end up being signaled as a very large receive window.

However, that change also signals at least TCP_MAXWIN, even when the socket receive buffer may be much smaller.

And the typecast long was missed in your fix-up to get rid of all longs in the tcp stack 😉.

Background is a interoperability issue, where we signal a shrunk scaled window too prematurely for certain remote hosts (older Linux clients).

While Linux simply does a roundup2(recwin, 1<<rec_scale), that may end up signaling a right edge of the receive window beyond what the socket buffer can support. 

But that change alone (only roundup2 to the signalled-out recwin) does work without unintended side effects, as tcp will apparently honor it’s committed and signaled receive window.

So based on the above change, it appears that no adjustment of the socket buffer size has to be done…

Best regards,

Richard Scheffenegger
Consulting Solution Architect
NAS & Networking

NetApp
+43 1 3676 811 3157 Direct Phone
+43 664 8866 1857 Mobile Phone
Richard.Scheffenegger at netapp.com





 
 #DataDriven

https://ts.la/richard49892