From nobody Tue Sep 9 16:20:07 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B4F6F28312D; Sun, 7 Sep 2025 15:33:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757259189; cv=none; b=V/qNtMU6rX8bZo5H09NZGPKpHgan681YFRWjrzYMaq16N2efAnes0WTnt30c1R9nx7aHKSVbNtksF4ACbUA7M3gYq0uHDYOmIvVNN5CMvvk5piUhbi5Y/4ylyrTRZmwtTO+2uT05ZvdiWz94sjoKNcRWdmZ9/dHTFMD4VrpQtv0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757259189; c=relaxed/simple; bh=mX9xiuWhw94j6IoO98BR9E5TyWLzVUtyfa496iHMOfs=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=AU0Er7C81id+lxjn3/Hpxd7cMuFmAoFXljp/2Etgs8B0jOcpoG5l0/8sT2CcXgTY4CY0D1rJOupvLfJ9GyZ+kZqKquoYInnwyQgtuOEfqljkG5hudNayF09RiZB6YebfItoV8T4rG/z429fmyLYT7nYh5ke2B4CitiJuHP4ncAs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rzC9dVx7; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rzC9dVx7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4B98AC4CEFE; Sun, 7 Sep 2025 15:33:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1757259189; bh=mX9xiuWhw94j6IoO98BR9E5TyWLzVUtyfa496iHMOfs=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=rzC9dVx7lW95ezuxrk7WM+FGZ0QBDbRgujI6P7svzLvv3PHzqrWV5P9EyztQcGRYU fRJFy2FJfiAwCWlfnDtyuojILb6GhiLm1dQClMFs+8p/TwrmuusB0UAoMq6IgblYyP l+6SnQS6ceEbShltJnPa2GaP/BN0TOq2q5S+sRlfmAD2pCYgMPgYTz0gVzgrhdXd0T P1E/ULY5OD6ekMNXv5l3ourQaUop7VpxetKWut75agREAGX/UygYmB6Ma9U4Ajvdc3 utxwUfsuX2RaWc1BqxXhbA0HR8Lwy0KunPTZaMg3ML4xwC/G/pIYD+/NFFQOBA3oXF 98zFfF+L4Q9mA== From: "Matthieu Baerts (NGI0)" Date: Sun, 07 Sep 2025 17:32:42 +0200 Subject: [PATCH net-next 1/3] mptcp: make ADD_ADDR retransmission timeout adaptive Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250907-net-next-mptcp-add_addr-retrans-adapt-v1-1-824cc805772b@kernel.org> References: <20250907-net-next-mptcp-add_addr-retrans-adapt-v1-0-824cc805772b@kernel.org> In-Reply-To: <20250907-net-next-mptcp-add_addr-retrans-adapt-v1-0-824cc805772b@kernel.org> To: mptcp@lists.linux.dev, Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Jonathan Corbet , Shuah Khan Cc: netdev@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, "Matthieu Baerts (NGI0)" , Christoph Paasch , Geliang Tang X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=4651; i=matttbe@kernel.org; h=from:subject:message-id; bh=fMWnGvfcxJeoK7vUJLijfKLkoWF3gYKAIXDJbZpQ7lw=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGDL2Ll0trh9xKF9mX0ysWmf/5pl5Pvqft6RklDCUSl59d 7bXxTi3o5SFQYyLQVZMkUW6LTJ/5vMq3hIvPwuYOaxMIEMYuDgFYCJlLxj+13x59iTi9rPDNp4B l/hvyVfe/V1gdOPfnMlzOX967BHr8mBk2B6kHjeTObdzDUuo8bmdJ4smNIZyXG2d86d+YoPF8Y+ HWQA= X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Geliang Tang Currently the ADD_ADDR option is retransmitted with a fixed timeout. This patch makes the retransmission timeout adaptive by using the maximum RTO among all the subflows, while still capping it at the configured maximum value (add_addr_timeout_max). This improves responsiveness when establishing new subflows. Specifically: 1. Adds mptcp_adjust_add_addr_timeout() helper to compute the adaptive timeout. 2. Uses maximum subflow RTO (icsk_rto) when available. 3. Applies exponential backoff based on retransmission count. 4. Maintains fallback to configured max timeout when no RTO data exists. This slightly changes the behaviour of the MPTCP "add_addr_timeout" sysctl knob to be used as a maximum instead of a fixed value. But this is seen as an improvement: the ADD_ADDR might be sent quicker than before to improve the overall MPTCP connection. Also, the default value is set to 2 min, which was already way too long, and caused the ADD_ADDR not to be retransmitted for connections shorter than 2 minutes. Suggested-by: Matthieu Baerts (NGI0) Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/576 Reviewed-by: Christoph Paasch Signed-off-by: Geliang Tang Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) --- v2: no changes. --- Documentation/networking/mptcp-sysctl.rst | 8 +++++--- net/mptcp/pm.c | 28 ++++++++++++++++++++++++---- 2 files changed, 29 insertions(+), 7 deletions(-) diff --git a/Documentation/networking/mptcp-sysctl.rst b/Documentation/netw= orking/mptcp-sysctl.rst index 1683c139821e3ba6d9eaa3c59330a523d29f1164..1eb6af26b4a7acdedd575a126c5= 76210a78f0d4d 100644 --- a/Documentation/networking/mptcp-sysctl.rst +++ b/Documentation/networking/mptcp-sysctl.rst @@ -8,9 +8,11 @@ MPTCP Sysfs variables =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D =20 add_addr_timeout - INTEGER (seconds) - Set the timeout after which an ADD_ADDR control message will be - resent to an MPTCP peer that has not acknowledged a previous - ADD_ADDR message. + Set the maximum value of timeout after which an ADD_ADDR control message + will be resent to an MPTCP peer that has not acknowledged a previous + ADD_ADDR message. A dynamically estimated retransmission timeout based + on the estimated connection round-trip-time is used if this value is + lower than the maximum one. =20 Do not retransmit if set to 0. =20 diff --git a/net/mptcp/pm.c b/net/mptcp/pm.c index 136a380602cae872b76560649c924330e5f42533..204e1f61212e2be77a8476f024b= 59be67d04b80a 100644 --- a/net/mptcp/pm.c +++ b/net/mptcp/pm.c @@ -268,6 +268,27 @@ int mptcp_pm_mp_prio_send_ack(struct mptcp_sock *msk, return -EINVAL; } =20 +static unsigned int mptcp_adjust_add_addr_timeout(struct mptcp_sock *msk) +{ + const struct net *net =3D sock_net((struct sock *)msk); + unsigned int rto =3D mptcp_get_add_addr_timeout(net); + struct mptcp_subflow_context *subflow; + unsigned int max =3D 0; + + mptcp_for_each_subflow(msk, subflow) { + struct sock *ssk =3D mptcp_subflow_tcp_sock(subflow); + struct inet_connection_sock *icsk =3D inet_csk(ssk); + + if (icsk->icsk_rto > max) + max =3D icsk->icsk_rto; + } + + if (max && max < rto) + rto =3D max; + + return rto; +} + static void mptcp_pm_add_timer(struct timer_list *timer) { struct mptcp_pm_add_entry *entry =3D timer_container_of(entry, timer, @@ -292,7 +313,7 @@ static void mptcp_pm_add_timer(struct timer_list *timer) goto out; } =20 - timeout =3D mptcp_get_add_addr_timeout(sock_net(sk)); + timeout =3D mptcp_adjust_add_addr_timeout(msk); if (!timeout) goto out; =20 @@ -307,7 +328,7 @@ static void mptcp_pm_add_timer(struct timer_list *timer) =20 if (entry->retrans_times < ADD_ADDR_RETRANS_MAX) sk_reset_timer(sk, timer, - jiffies + timeout); + jiffies + (timeout << entry->retrans_times)); =20 spin_unlock_bh(&msk->pm.lock); =20 @@ -348,7 +369,6 @@ bool mptcp_pm_alloc_anno_list(struct mptcp_sock *msk, { struct mptcp_pm_add_entry *add_entry =3D NULL; struct sock *sk =3D (struct sock *)msk; - struct net *net =3D sock_net(sk); unsigned int timeout; =20 lockdep_assert_held(&msk->pm.lock); @@ -374,7 +394,7 @@ bool mptcp_pm_alloc_anno_list(struct mptcp_sock *msk, =20 timer_setup(&add_entry->add_timer, mptcp_pm_add_timer, 0); reset_timer: - timeout =3D mptcp_get_add_addr_timeout(net); + timeout =3D mptcp_adjust_add_addr_timeout(msk); if (timeout) sk_reset_timer(sk, &add_entry->add_timer, jiffies + timeout); =20 --=20 2.51.0 From nobody Tue Sep 9 16:20:07 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B096327F18B; Sun, 7 Sep 2025 15:33:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757259193; cv=none; b=OH5cEHTzbZgdbO+TtOD385QiUmGwieoQ8b0SUGavs4nQ20mx69B2FUFp7nmA4Jm5n3Upso+GMjU7zXvUydsWYlE9s4RlSuzxORgcpUC+zMuavuyg6lgwkbEtiyyeQfG4oFGXUfeze6YVvtsNLNvE8BVrIRfAiacSA6He+YAV8DA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757259193; c=relaxed/simple; bh=pNHM5twt0DKjZhFVjKYzgZKU7n8BlxsD8d5xFnhet24=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=naOz72cKNF0If2/X+i07MgSn6T5WlETgJHttAkH/Fr5IVbPg9CXMyFjMMqltfFpOBOMi+9WMZ/V88dtw7E//EM/devxH+38FAydTFgei1CJJl2VMlzp53ANICYLpBuuvJdGCZBaeQKsgQi9Si6iVE4wEaYNP+q8VizIfYx3UT6I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=maVfkJvI; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="maVfkJvI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 99741C4CEF0; Sun, 7 Sep 2025 15:33:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1757259192; bh=pNHM5twt0DKjZhFVjKYzgZKU7n8BlxsD8d5xFnhet24=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=maVfkJvI4JqjyuJh/sIII/bX/aWYhsOjZRU2UTPvEC8sDK4wS6omlPR9nHZ6aZeSc IBXzsWiNDVYdCiHo0W0Fr33gLt9cPWMovUPm6wrRPytW4ETm2mw1zPhw5oTgGdmJxq vI8U+GnqL9MPM5lP2CnQv7D+ngHykDjIshHIMUfM73OHLK64eQpuK/Hh83zp/JgVZ6 0uz1mDnN7HyTRIPuDdPrrcKerITUblJRyGFdtpp8vm2OWRN0KvVK1maiYHg7iJgEAD U6EBilRh9slpZSfYQTBG/xAp/iMKho7HPaKpqnwLS58dJRRrkMDd0qO8L7qoKibWaj eYgdrKRTBgytA== From: "Matthieu Baerts (NGI0)" Date: Sun, 07 Sep 2025 17:32:43 +0200 Subject: [PATCH net-next 2/3] selftests: mptcp: join: tolerate more ADD_ADDR Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250907-net-next-mptcp-add_addr-retrans-adapt-v1-2-824cc805772b@kernel.org> References: <20250907-net-next-mptcp-add_addr-retrans-adapt-v1-0-824cc805772b@kernel.org> In-Reply-To: <20250907-net-next-mptcp-add_addr-retrans-adapt-v1-0-824cc805772b@kernel.org> To: mptcp@lists.linux.dev, Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Jonathan Corbet , Shuah Khan Cc: netdev@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, "Matthieu Baerts (NGI0)" X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=3664; i=matttbe@kernel.org; h=from:subject:message-id; bh=pNHM5twt0DKjZhFVjKYzgZKU7n8BlxsD8d5xFnhet24=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGDL2Ll3zW9Q6Y8252IeuxdwRW/8bT2t6+jni5hvloDyJx VlPixw8OkpZGMS4GGTFFFmk2yLzZz6v4i3x8rOAmcPKBDKEgYtTACYSMZmRoXsC/yMLxuQndw0r F67gUWtke+Azd+PiJI5fd3ttODPFPjH8r15v/2NvJ7dozn/tQ+eYVr/hOFt0Uea1+cZH3RmrinO suQE= X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 ADD_ADDR can be retransmitted, and with, the parent commit, these retransmissions can be sent quicker: from 2 minutes to less than one second. To avoid false positives where retransmitted ADD_ADDR causes higher counters than expected, it is required to be more tolerant. Errors are now only reported when fewer ADD_ADDRs have been sent/received, except if no ADD_ADDR are expected. Before the parent commit, the tolerance was present for each tests where the ADD_ADDR could be retransmitted in a reasonable time (1 sec). Now that all tests can have retransmitted ADD_ADDR, it is normal to apply the same tolerance for all tests. An alternative could be to disable the ADD_ADDR retransmissions by default, but that's changing the default kernel behaviour. Plus, ADD_ADDR retransmissions can be required for some tests. To avoid adding exceptions to many tests, it seems better to increase the tolerance. Later, we could add a new MIB counter to identify the ADD_ADDR retransmissions, and remove the tolerance when this counter is available. Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) --- tools/testing/selftests/net/mptcp/mptcp_join.sh | 19 +++++++------------ 1 file changed, 7 insertions(+), 12 deletions(-) diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testin= g/selftests/net/mptcp/mptcp_join.sh index 2f046167a0b6cc6fb5531a033d8d95c9ea399cf9..e9e11a9e60fd5374c8a98c3b715= 9ccbca8053030 100755 --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh @@ -358,6 +358,7 @@ reset_with_add_addr_timeout() tables=3D"${ip6tables}" fi =20 + # set a maximum, to avoid too long timeout with exponential backoff ip netns exec $ns1 sysctl -q net.mptcp.add_addr_timeout=3D1 =20 if ! ip netns exec $ns2 $tables -A OUTPUT -p tcp \ @@ -1669,7 +1670,6 @@ chk_add_nr() local tx=3D"" local rx=3D"" local count - local timeout =20 if [[ $ns_invert =3D "invert" ]]; then ns_tx=3D$ns2 @@ -1678,15 +1678,13 @@ chk_add_nr() rx=3D" server" fi =20 - timeout=3D$(ip netns exec ${ns_tx} sysctl -n net.mptcp.add_addr_timeout) - print_check "add addr rx${rx}" count=3D$(mptcp_lib_get_counter ${ns_rx} "MPTcpExtAddAddr") if [ -z "$count" ]; then print_skip - # if the test configured a short timeout tolerate greater then expected - # add addrs options, due to retransmissions - elif [ "$count" !=3D "$add_nr" ] && { [ "$timeout" -gt 1 ] || [ "$count" = -lt "$add_nr" ]; }; then + # Tolerate more ADD_ADDR then expected (if any), due to retransmissions + elif [ "$count" !=3D "$add_nr" ] && + { [ "$add_nr" -eq 0 ] || [ "$count" -lt "$add_nr" ]; }; then fail_test "got $count ADD_ADDR[s] expected $add_nr" else print_ok @@ -1774,18 +1772,15 @@ chk_add_tx_nr() { local add_tx_nr=3D$1 local echo_tx_nr=3D$2 - local timeout local count =20 - timeout=3D$(ip netns exec $ns1 sysctl -n net.mptcp.add_addr_timeout) - print_check "add addr tx" count=3D$(mptcp_lib_get_counter ${ns1} "MPTcpExtAddAddrTx") if [ -z "$count" ]; then print_skip - # if the test configured a short timeout tolerate greater then expected - # add addrs options, due to retransmissions - elif [ "$count" !=3D "$add_tx_nr" ] && { [ "$timeout" -gt 1 ] || [ "$coun= t" -lt "$add_tx_nr" ]; }; then + # Tolerate more ADD_ADDR then expected (if any), due to retransmissions + elif [ "$count" !=3D "$add_tx_nr" ] && + { [ "$add_tx_nr" -eq 0 ] || [ "$count" -lt "$add_tx_nr" ]; }; then fail_test "got $count ADD_ADDR[s] TX, expected $add_tx_nr" else print_ok --=20 2.51.0 From nobody Tue Sep 9 16:20:07 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0E60627F18B; Sun, 7 Sep 2025 15:33:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757259197; cv=none; b=iebadbIZC3ZZQFZ0fpr+if4ggKBR4bkxQZ9KF13yDtNgzzupqh+fNKDCAqsGu1f06xKVVG0ZKwzFwEiAGZupbl+hQV77duIeewpIW0spKld4IT+CtOvxLHeAy4dpv1psby4ANq8TDRioguvxHQkwE4gCSnFcIBPWwwU/OiwAx1E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757259197; c=relaxed/simple; bh=stiQPhak8MOP6pYZdLyutUNcmHegMkQrARaC/Ai+XFA=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=e9Kl+YcnFW5BiJOFL+1Q3ODXQMz7OARgSHtoKBFR9KQPMxxKcP7yZ5Klu7f16VetRmzcPIMk9zMwDjWFO/TKYWWxvl+l0uN+AKYUklSrEDo54U/QycB+VAJXThfo27lcx2oZChFSC1G999iqZfcFA+G/jOsrsokttTDHWqPyk1k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oV1qXewn; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="oV1qXewn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BD218C4CEF5; Sun, 7 Sep 2025 15:33:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1757259195; bh=stiQPhak8MOP6pYZdLyutUNcmHegMkQrARaC/Ai+XFA=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=oV1qXewnDKnbIJFTqiUEeQSwC/3McmLPaxozGZiGZS4XPia3fck2g4HagmezLSevB q0pdBFKlGsmp3PcrO1qLRnwP82jG7KdW9YW5zybjKh9TxrXlkqToYp04fV9gQ5jty2 hlImczw3DAS+vt19Gdj+rw0gbEFo/Ct9/Vs0jMQ+heMMkIq4piSxnDb1k+rFs7ORHp jXA/pknZpbHxlfpQT4W1nQ4Tns6yb//nYLVPjU7qVKxa7Jf8k6LAhPWzSg1Jyzlw5g EgtZWsPaVenSSDEF9sjuqGq+cDPcOxw6EPLqr9Fzih/IrG4p5j6cpoUNeGecz1h56c jEVxvqfJ1U6jw== From: "Matthieu Baerts (NGI0)" Date: Sun, 07 Sep 2025 17:32:44 +0200 Subject: [PATCH net-next 3/3] selftests: mptcp: join: allow more time to send ADD_ADDR Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250907-net-next-mptcp-add_addr-retrans-adapt-v1-3-824cc805772b@kernel.org> References: <20250907-net-next-mptcp-add_addr-retrans-adapt-v1-0-824cc805772b@kernel.org> In-Reply-To: <20250907-net-next-mptcp-add_addr-retrans-adapt-v1-0-824cc805772b@kernel.org> To: mptcp@lists.linux.dev, Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Jonathan Corbet , Shuah Khan Cc: netdev@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, "Matthieu Baerts (NGI0)" X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=1515; i=matttbe@kernel.org; h=from:subject:message-id; bh=stiQPhak8MOP6pYZdLyutUNcmHegMkQrARaC/Ai+XFA=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGDL2Ll03M+ezbfADr3m8AZMe8TRyNYUadN31K9z+2fpty ycOTsVlHaUsDGJcDLJiiizSbZH5M59X8ZZ4+VnAzGFlAhnCwMUpABOxF2ZkWJds57F+s/mG38ma 8gxheh2vV6pP7NK++q+Xh0ffKGimCCPDFT0jhRV3OQ4Ua+pqSU1o5jbj3sHp3re59vbylSvEeXy YAA== X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 When many ADD_ADDR need to be sent, it can take some time to send each of them, and create new subflows. Some CIs seem to occasionally have issues with these tests, especially with "debug" kernels. Two subtests will now run for a slightly longer time: the last two where 3 or more ADD_ADDR are sent during the test. Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) --- tools/testing/selftests/net/mptcp/mptcp_join.sh | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testin= g/selftests/net/mptcp/mptcp_join.sh index e9e11a9e60fd5374c8a98c3b7159ccbca8053030..b41cebfa1f921ce9ea6a88a908b= f6d5e6027b367 100755 --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh @@ -2268,7 +2268,8 @@ signal_address_tests() pm_nl_add_endpoint $ns1 10.0.3.1 flags signal pm_nl_add_endpoint $ns1 10.0.4.1 flags signal pm_nl_set_limits $ns2 3 3 - run_tests $ns1 $ns2 10.0.1.1 + speed=3Dslow \ + run_tests $ns1 $ns2 10.0.1.1 chk_join_nr 3 3 3 chk_add_nr 3 3 fi @@ -2280,7 +2281,8 @@ signal_address_tests() pm_nl_add_endpoint $ns1 10.0.3.1 flags signal pm_nl_add_endpoint $ns1 10.0.14.1 flags signal pm_nl_set_limits $ns2 3 3 - run_tests $ns1 $ns2 10.0.1.1 + speed=3Dslow \ + run_tests $ns1 $ns2 10.0.1.1 join_syn_tx=3D3 \ chk_join_nr 1 1 1 chk_add_nr 3 3 --=20 2.51.0