netdev - Re: [PATCH net] tcp: tsq: relax tcp_small_queue_check() when rtx queue contains a single skb

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: <b0f3d278-5da3-4ef8-8b9b-2cb439e2e88f@gmx.net>
Date: Tue, 17 Oct 2023 16:38:49 +0200
From: Stefan Wahren <wahrenst@....net>
To: Eric Dumazet <edumazet@...gle.com>, "David S . Miller"
 <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>
Cc: netdev@...r.kernel.org, eric.dumazet@...il.com,
 Neal Cardwell <ncardwell@...gle.com>
Subject: Re: [PATCH net] tcp: tsq: relax tcp_small_queue_check() when rtx
 queue contains a single skb

Hi,

Am 17.10.23 um 14:45 schrieb Eric Dumazet:
> In commit 75eefc6c59fd ("tcp: tsq: add a shortcut in tcp_small_queue_check()")
> we allowed to send an skb regardless of TSQ limits being hit if rtx queue
> was empty or had a single skb, in order to better fill the pipe
> when/if TX completions were slow.
>
> Then later, commit 75c119afe14f ("tcp: implement rb-tree based
> retransmit queue") accidentally removed the special case for
> one skb in rtx queue.
>
> Stefan Wahren reported a regression in single TCP flow throughput
> using a 100Mbit fec link, starting from commit 65466904b015 ("tcp: adjust
> TSO packet sizes based on min_rtt"). This last commit only made the
> regression more visible, because it locked the TCP flow on a particular
> behavior where TSQ prevented two skbs being pushed downstream,
> adding silences on the wire between each TSO packet.
>
> Many thanks to Stefan for his invaluable help !
>
just some figures using my ARM platform (Tarragon) as iperf client and a
PC (Ubuntu 22.04) as iperf server.

Using current net ( 95535e37e895 ) without the patch

# iperf -t 10 -i 1 -c 192.168.1.129
------------------------------------------------------------
Client connecting to 192.168.1.129, TCP port 5001
TCP window size: 96.2 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.12 port 33152 connected with 192.168.1.129 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec  10.1 MBytes  84.9 Mbits/sec
[  3]  1.0- 2.0 sec  9.62 MBytes  80.7 Mbits/sec
[  3]  2.0- 3.0 sec  9.62 MBytes  80.7 Mbits/sec
[  3]  3.0- 4.0 sec  9.62 MBytes  80.7 Mbits/sec
[  3]  4.0- 5.0 sec  9.62 MBytes  80.7 Mbits/sec
[  3]  5.0- 6.0 sec  9.62 MBytes  80.7 Mbits/sec
[  3]  6.0- 7.0 sec  9.62 MBytes  80.7 Mbits/sec
[  3]  7.0- 8.0 sec  9.75 MBytes  81.8 Mbits/sec
[  3]  8.0- 9.0 sec  9.62 MBytes  80.7 Mbits/sec
[  3]  9.0-10.0 sec  10.0 MBytes  83.9 Mbits/sec
[  3]  0.0-10.0 sec  97.2 MBytes  81.5 Mbits/sec

Using current net with applied patch

# iperf -t 10 -i 1 -c 192.168.1.129
------------------------------------------------------------
Client connecting to 192.168.1.129, TCP port 5001
TCP window size: 96.2 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.12 port 32854 connected with 192.168.1.129 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec  11.5 MBytes  96.5 Mbits/sec
[  3]  1.0- 2.0 sec  11.4 MBytes  95.4 Mbits/sec
[  3]  2.0- 3.0 sec  11.2 MBytes  94.4 Mbits/sec
[  3]  3.0- 4.0 sec  11.1 MBytes  93.3 Mbits/sec
[  3]  4.0- 5.0 sec  11.2 MBytes  94.4 Mbits/sec
[  3]  5.0- 6.0 sec  11.2 MBytes  94.4 Mbits/sec
[  3]  6.0- 7.0 sec  11.1 MBytes  93.3 Mbits/sec
[  3]  7.0- 8.0 sec  11.2 MBytes  94.4 Mbits/sec
[  3]  8.0- 9.0 sec  11.2 MBytes  94.4 Mbits/sec
[  3]  9.0-10.0 sec  11.2 MBytes  94.4 Mbits/sec
[  3]  0.0-10.0 sec   113 MBytes  94.4 Mbits/sec

Thanks