netdev - Re: Potential impact of commit dfa2f0483360 ("tcp: get rid of sysctl_tcp_adv_win

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <262f14e5-a6ca-428c-af5c-dbe677e86cb3@quicinc.com>
Date: Thu, 16 May 2024 12:49:01 -0600
From: "Subash Abhinov Kasiviswanathan (KS)" <quic_subashab@...cinc.com>
To: Eric Dumazet <edumazet@...gle.com>
CC: <soheil@...gle.com>, <ncardwell@...gle.com>, <yyd@...gle.com>,
        <ycheng@...gle.com>, <quic_stranche@...cinc.com>,
        <davem@...emloft.net>, <kuba@...nel.org>, <netdev@...r.kernel.org>
Subject: Re: Potential impact of commit dfa2f0483360 ("tcp: get rid of
 sysctl_tcp_adv_win_scale")

On 5/16/2024 2:31 AM, Eric Dumazet wrote:
> On Thu, May 16, 2024 at 9:57 AM Eric Dumazet <edumazet@...gle.com> wrote:
>>
>> On Thu, May 16, 2024 at 9:16 AM Subash Abhinov Kasiviswanathan (KS)
>> <quic_subashab@...cinc.com> wrote:
>>>
>>> On 5/15/2024 11:36 PM, Eric Dumazet wrote:
>>>> On Thu, May 16, 2024 at 4:32 AM Subash Abhinov Kasiviswanathan (KS)
>>>> <quic_subashab@...cinc.com> wrote:
>>>>>
>>>>> On 5/15/2024 1:10 AM, Eric Dumazet wrote:
>>>>>> On Wed, May 15, 2024 at 6:47 AM Subash Abhinov Kasiviswanathan (KS)
>>>>>> <quic_subashab@...cinc.com> wrote:
>>>>>>>
>>>>>>> We recently noticed that a device running a 6.6.17 kernel (A) was having
>>>>>>> a slower single stream download speed compared to a device running
>>>>>>> 6.1.57 kernel (B). The test here is over mobile radio with iperf3 with
>>>>>>> window size 4M from a third party server.
>>>>>>
>>>>
>>> I tried 0.5MB for the rmem[1] and I see the same behavior where the
>>> receiver window is not scaling beyond half of what is specified on
>>> iperf3 and is not matching the download speed of B.
>>
>>
>> What do you mean by "specified by iperf3" ?
>>
>> We can not guarantee any stable performance for applications setting SO_RCVBUF.
>>
>> This is because the memory overhead depends from one version to the other.
> 
> Issue here is that SO_RCVBUF is set before TCP has a chance to receive
> any packets.
> 
> Sensing the skb->len/skb->truesize is not possible.
> 
> Therefore the default value is conservative, and might not be good for
> your case.
> 
> This is not fixable easily, because tp->window_clamp has been
> historically abused.
> 
> TCP_WINDOW_CLAMP socket option should have used a separate tcp socket field
> to remember tp->window_clamp has been set (fixed) to a user value.
> 
> Make sure you have this followup patch, dealing with applications
> still needing to make TCP slow.
> 
> commit 697a6c8cec03c2299f850fa50322641a8bf6b915
> Author: Hechao Li <hli@...flix.com>
> Date:   Tue Apr 9 09:43:55 2024 -0700
> 
>      tcp: increase the default TCP scaling ratio
Thanks! After applying it, I definitely see the increase in receiver 
window to ~4M with 4M SO_RCVBUF in my local device. Seems like this 
patch hasn't trickled down to 6.6 so far.

>> What happens if you let autotuning enabled ?
I'll try this test and also the test with 4M SO_RCVBUF on the device 
configuration where the download issue was observed and report back with 
the findings.