[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20201207105345.4a4474f3@kicinski-fedora-pc1c0hjn.DHCP.thefacebook.com>
Date: Mon, 7 Dec 2020 10:53:45 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Hazem Mohamed Abuelfotoh <abuehaze@...zon.com>
Cc: <netdev@...r.kernel.org>, <stable@...r.kernel.org>,
<edumazet@...gle.com>, <ycheng@...gle.com>, <ncardwell@...gle.com>,
<weiwan@...gle.com>, <astroh@...zon.com>, <benh@...zon.com>
Subject: Re: [PATCH net] tcp: fix receive buffer autotuning to trigger for
any valid advertised MSS
On Mon, 7 Dec 2020 11:46:25 +0000 Hazem Mohamed Abuelfotoh wrote:
> Previously receiver buffer auto-tuning starts after receiving
> one advertised window amount of data.After the initial
> receiver buffer was raised by
> commit a337531b942b ("tcp: up initial rmem to 128KB
> and SYN rwin to around 64KB"),the receiver buffer may
> take too long for TCP autotuning to start raising
> the receiver buffer size.
> commit 041a14d26715 ("tcp: start receiver buffer autotuning sooner")
> tried to decrease the threshold at which TCP auto-tuning starts
> but it's doesn't work well in some environments
> where the receiver has large MTU (9001) especially with high RTT
> connections as in these environments rcvq_space.space will be the same
> as rcv_wnd so TCP autotuning will never start because
> sender can't send more than rcv_wnd size in one round trip.
> To address this issue this patch is decreasing the initial
> rcvq_space.space so TCP autotuning kicks in whenever the sender is
> able to send more than 5360 bytes in one round trip regardless the
> receiver's configured MTU.
>
> Fixes: a337531b942b ("tcp: up initial rmem to 128KB and SYN rwin to around 64KB")
> Fixes: 041a14d26715 ("tcp: start receiver buffer autotuning sooner")
>
> Signed-off-by: Hazem Mohamed Abuelfotoh <abuehaze@...zon.com>
If the discussion concludes in favor of this patch please un-indent
this commit message, remove the empty line after the fixes tag, and
repost.
Powered by blists - more mailing lists