[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20240517085031.18896-1-kerneljasonxing@gmail.com>
Date: Fri, 17 May 2024 16:50:31 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: edumazet@...gle.com,
dsahern@...nel.org,
kuba@...nel.org,
pabeni@...hat.com,
davem@...emloft.net,
ncardwell@...gle.com
Cc: netdev@...r.kernel.org,
kerneljasonxing@...il.com,
Jason Xing <kernelxing@...cent.com>
Subject: [RFC PATCH net-next] tcp: break the limitation of initial receive window
From: Jason Xing <kernelxing@...cent.com>
Since in 2018 one commit a337531b942b ("tcp: up initial rmem to 128KB and
SYN rwin to around 64KB") limited received window within 65535, most CDN
team would not benefit from this change because they cannot have a large
window to receive a big packet one time especially in long RTT.
According to RFC 7323, it says:
"The maximum receive window, and therefore the scale factor, is
determined by the maximum receive buffer space."
So we can get rid of this 64k limitation and let the window be tunable if
the user wants to do it within the control of buffer space. Then many
companies, I believe, can have the same behaviour as old days. Besides,
there are many papers conducting various interesting experiments which
have something to do with this window and show good outputs in some cases.
Signed-off-by: Jason Xing <kernelxing@...cent.com>
---
net/ipv4/tcp_output.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 95caf8aaa8be..95618d0e78e4 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -232,7 +232,7 @@ void tcp_select_initial_window(const struct sock *sk, int __space, __u32 mss,
if (READ_ONCE(sock_net(sk)->ipv4.sysctl_tcp_workaround_signed_windows))
(*rcv_wnd) = min(space, MAX_TCP_WINDOW);
else
- (*rcv_wnd) = min_t(u32, space, U16_MAX);
+ (*rcv_wnd) = space;
if (init_rcv_wnd)
*rcv_wnd = min(*rcv_wnd, init_rcv_wnd * mss);
--
2.37.3
Powered by blists - more mailing lists