From nobody Wed Sep 17 16:19:50 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 0368730C342; Mon, 1 Sep 2025 09:40:03 +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=1756719604; cv=none; b=PK0lNp9Z8ynyCH11vXlkYRb6PGR20aHOiyu1d9O6sM2WEFifZGfe2hiiTd420MC1qlSSXC8QeGyPtAakP2ADg+3ao5Sj/zfWsneVVXI/GLtOOeQ89X1TTBhKZLthmkKsBwzJeLG5jBJhja+qHK9hQMwiC3zeBxeRYxp+/2Uo974= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756719604; c=relaxed/simple; bh=CqNBy4qAhqOnrt+73tr37KOH8EL1eioRr8crEmdVuQY=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=DMC3KH7jiGyTHqZRiC1NVh+VpnfU29S+dkof04wzySewwmxcNwtfElJVB+72taXsjqAd8Wq7M2K3BKBKeGiHVheZuglDd35UVFLidqyCSOvyBEwhiERpjp7Gqj1kfpEFMMpaVxjd02uoFhk7yTdO+weRlGcMMeoc/LeSvqsf5e0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sXipAA0Q; 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="sXipAA0Q" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 902EFC4CEF4; Mon, 1 Sep 2025 09:40:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756719603; bh=CqNBy4qAhqOnrt+73tr37KOH8EL1eioRr8crEmdVuQY=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=sXipAA0QCofcHNIb2Znq7ydPl5lTRqyowO6PNMVlVOT4Ux49+NIqV3UzjrelU45nn GZtOLFXHqB9M4A9Ygwce9pgWBsPkl4s5f4Hz1o1DmUE2PaRcIaQxxTqFPdvNHhDl3R rvA3U9IaFcEgCIED5P7FEL31V04UUXgl1hWQdQhpSJoDpD/+UyiIVaSxlKU3F/5KTa TD1HR3IOXkgch+3s6lu9tBODW2Z2anhsIwhk9qG2oN9INyR2Cq2s7/2sbEbJ1sr3ht ommNekT5GDcNGvbfupgO3wdnCWMcZbaAFaZB2GLJ8TbyXc0TqE2fHqm9cc4GI7tTPq R1CEFaYnJSIAA== From: "Matthieu Baerts (NGI0)" Date: Mon, 01 Sep 2025 11:39:10 +0200 Subject: [PATCH net-next 1/6] mptcp: use HMAC-SHA256 library instead of open-coded HMAC Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250901-net-next-mptcp-misc-feat-6-18-v1-1-80ae80d2b903@kernel.org> References: <20250901-net-next-mptcp-misc-feat-6-18-v1-0-80ae80d2b903@kernel.org> In-Reply-To: <20250901-net-next-mptcp-misc-feat-6-18-v1-0-80ae80d2b903@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-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, "Matthieu Baerts (NGI0)" , Eric Biggers X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=2283; i=matttbe@kernel.org; h=from:subject:message-id; bh=hw8hY2SZgWZHzkPlV37CbfZ5OCuLt+l36o5ACPxGzR8=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGDK2Zj7l2P5UQvx6v75NXd86TWeuD7HbpMzvzksSOpXmL nlbT1+uo5SFQYyLQVZMkUW6LTJ/5vMq3hIvPwuYOaxMIEMYuDgFYCL6igx/OPdOzZXoMD76kfHS /d1bMuK+bfyQ5TBhm/J/MWe7/PTXJxj+CqhMcI/+qSzF3v9KYY7ZL9Plbp/zWrmin26/k5sr7+f OAQA= X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Eric Biggers Now that there are easy-to-use HMAC-SHA256 library functions, use these in net/mptcp/crypto.c instead of open-coding the HMAC algorithm. Remove the WARN_ON_ONCE() for messages longer than SHA256_DIGEST_SIZE. The new implementation handles all message lengths correctly. The mptcp-crypto KUnit test still passes after this change. Signed-off-by: Eric Biggers Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/crypto.c | 35 ++--------------------------------- 1 file changed, 2 insertions(+), 33 deletions(-) diff --git a/net/mptcp/crypto.c b/net/mptcp/crypto.c index b08ba959ac4fd485bb833043ff58d4c8bac8a37a..31948e18d97da7ee0ee2ae9e4f7= c9ca0e3b330a7 100644 --- a/net/mptcp/crypto.c +++ b/net/mptcp/crypto.c @@ -22,7 +22,6 @@ =20 #include #include -#include =20 #include "protocol.h" =20 @@ -43,39 +42,9 @@ void mptcp_crypto_key_sha(u64 key, u32 *token, u64 *idsn) =20 void mptcp_crypto_hmac_sha(u64 key1, u64 key2, u8 *msg, int len, void *hma= c) { - u8 input[SHA256_BLOCK_SIZE + SHA256_DIGEST_SIZE]; - u8 key1be[8]; - u8 key2be[8]; - int i; + __be64 key[2] =3D { cpu_to_be64(key1), cpu_to_be64(key2) }; =20 - if (WARN_ON_ONCE(len > SHA256_DIGEST_SIZE)) - len =3D SHA256_DIGEST_SIZE; - - put_unaligned_be64(key1, key1be); - put_unaligned_be64(key2, key2be); - - /* Generate key xored with ipad */ - memset(input, 0x36, SHA256_BLOCK_SIZE); - for (i =3D 0; i < 8; i++) - input[i] ^=3D key1be[i]; - for (i =3D 0; i < 8; i++) - input[i + 8] ^=3D key2be[i]; - - memcpy(&input[SHA256_BLOCK_SIZE], msg, len); - - /* emit sha256(K1 || msg) on the second input block, so we can - * reuse 'input' for the last hashing - */ - sha256(input, SHA256_BLOCK_SIZE + len, &input[SHA256_BLOCK_SIZE]); - - /* Prepare second part of hmac */ - memset(input, 0x5C, SHA256_BLOCK_SIZE); - for (i =3D 0; i < 8; i++) - input[i] ^=3D key1be[i]; - for (i =3D 0; i < 8; i++) - input[i + 8] ^=3D key2be[i]; - - sha256(input, SHA256_BLOCK_SIZE + SHA256_DIGEST_SIZE, hmac); + hmac_sha256_usingrawkey((const u8 *)key, sizeof(key), msg, len, hmac); } =20 #if IS_MODULE(CONFIG_MPTCP_KUNIT_TEST) --=20 2.50.1 From nobody Wed Sep 17 16:19:50 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 50AB630C342; Mon, 1 Sep 2025 09:40:06 +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=1756719607; cv=none; b=ZwNJqJaqqsuYu739Pb9NY38/rAjvC+xTndY4uWxh2nd2LFWVYlQBoUYHdHqDxFYQlSUYgmmNTvfRzSkgoAHnFoZpvmfG8F62nXLgLliyn/7pcmBe9AsesV8dmENev/BC7INBBle2rWMtstqYtth0w+efvJvqiAlE7KxUxcoFZj8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756719607; c=relaxed/simple; bh=t66zpO9Pqc9pdQrY0JVlXxMhyauM8n6tmv5uzLGlpi8=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=lPu5dhXzeS+Cy5wffoWcx02PEh8joU5PnUveZjFeya6KYmjMF0/M2da9Dhk/QodvlknyJU98R6oTLdFHfe6MHIbQOkzmrJRcxTJby+GD5z4YCSqEWqmDKKvN2GgpJR5RQUlIiZta8D5HjVTvU353difX3H4vGiM4+ydUAneNOD4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Z8YbcKW4; 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="Z8YbcKW4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E5EA6C4CEF7; Mon, 1 Sep 2025 09:40:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756719606; bh=t66zpO9Pqc9pdQrY0JVlXxMhyauM8n6tmv5uzLGlpi8=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=Z8YbcKW45tSfMJE9nAGyb4uDSSYylrLTN7u9+E+8dmFXMlS9fVwcsH0VFd9heFm50 1SQSfggeYwQ0rguYXFk3hNMKYOQpmympNvFRIAu0Q0rHUEuR+ZT5Zbq9LzHEOQPtDG 08JFpxdBnLZxrmbDIfAPpIL+1FS7XklIFQWBYLGXHdBRUGtYPtEF8+zkLOrnhqZBgP 0CCwXuqijg1p32gtrcmULmNvM6h2OFKLrPG1oBNXr+CGGjRg0jBoh12GSBfEtFSgl+ FDf/bvFTfLnndVw9yBZzlLAhUv15pCkMPXIMHRsbRM5XUHcM9zGAQ4QC+pfejkfQTe zFisQ/Nm9ICQA== From: "Matthieu Baerts (NGI0)" Date: Mon, 01 Sep 2025 11:39:11 +0200 Subject: [PATCH net-next 2/6] mptcp: make ADD_ADDR retransmission timeout adaptive Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250901-net-next-mptcp-misc-feat-6-18-v1-2-80ae80d2b903@kernel.org> References: <20250901-net-next-mptcp-misc-feat-6-18-v1-0-80ae80d2b903@kernel.org> In-Reply-To: <20250901-net-next-mptcp-misc-feat-6-18-v1-0-80ae80d2b903@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-kernel@vger.kernel.org, linux-doc@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=4629; i=matttbe@kernel.org; h=from:subject:message-id; bh=kQ5I77pkzfwFmuOeSNqXsuaFXlb1YAyOD+9P38RrVCc=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGDK2Zj5TrPpS9zDkSUQ8l2B0TlWv0tMfSQ9mnXu35pmz9 /aAgsvRHaUsDGJcDLJiiizSbZH5M59X8ZZ4+VnAzGFlAhnCwMUpABPR/cHIcI7jt5FSV9OjxVFu QU8Ovfu4hvP/qcuxPU5hPHIck3X7zzD8T9KbdPb7o/7vp2X+2v3kWPKwYO2StrOmO67ztweLTlf fww0A 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) --- 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.50.1 From nobody Wed Sep 17 16:19:50 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 762FB30EF7E; Mon, 1 Sep 2025 09:40:10 +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=1756719610; cv=none; b=EkHv/6REXGvl15MTby2aCgCJANmSysf2LYGpJ6WxsO/IHK7R4VoQ93jjF3FO4/h0cFcprMjST1sZPt6FL/t7kqO+tD/3vJx0QZAjh8Y5YmXJYWRjhk7OHN6MufYigV3Ws7RzG1tvS2UiUPiBDhvzsQ375Sv1z3bg7V0Le1n49Vk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756719610; c=relaxed/simple; bh=k+CIqM4/nq+cvAampNpahv2V1eFDkAil5XdpuBPEHm4=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=M1v0bbyClRZalFh3kEmiZ6CgMRPaAA6gVM1/RgJtjIyaQMhGTG8gHK2eYYdS9FQFVF41kBJdsnnu6flhvBVOaymXxxQT0oBOhMyS2oVcko2X4/l+EfCQOCJB1jUC5RfZdweNMc6Y4y8qmd9HNa6G2j6IEurP0Dxk9dQlQ9rlQ/A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=t6RgGr8z; 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="t6RgGr8z" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 46117C4CEF4; Mon, 1 Sep 2025 09:40:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756719610; bh=k+CIqM4/nq+cvAampNpahv2V1eFDkAil5XdpuBPEHm4=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=t6RgGr8zIwVdGJbste4SsJLTdIYI8Dr0BhQtuSfKAmaiyrjmonfKirJX0N8epjZ+W RhT4bCXMzIHj5ClHBP5jRjKyH10RumqZ0WrH7c9TquiMOhR+uNIl/4NcNmYXu1+He1 fOgV0TxbFM3vqc2nALeQUb2YeNQtsOLmaimX92i/eg/92X+qPhJadpd5wsw90W7QCb hTW8A9VpI8wRPVqC3RNEHJpB9dYwhRbR1ghQIKu22h+5m9Hme0S0Ukjaz3l0/uovgc 4APPWQ5SkHotc3LMW79exIdeYKjLpC8HKr2CnhBt82XPLSCcP0HrtZzQmaJbgTLOWT J7/2wn/KhsVpg== From: "Matthieu Baerts (NGI0)" Date: Mon, 01 Sep 2025 11:39:12 +0200 Subject: [PATCH net-next 3/6] selftests: mptcp: remove add_addr_timeout settings Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250901-net-next-mptcp-misc-feat-6-18-v1-3-80ae80d2b903@kernel.org> References: <20250901-net-next-mptcp-misc-feat-6-18-v1-0-80ae80d2b903@kernel.org> In-Reply-To: <20250901-net-next-mptcp-misc-feat-6-18-v1-0-80ae80d2b903@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-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, "Matthieu Baerts (NGI0)" , Geliang Tang X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=1522; i=matttbe@kernel.org; h=from:subject:message-id; bh=1nVFFqCHSNVwfmePtrb2XeOe0x0CCB6YRJAQqv0sIyM=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGDK2Zr54GtQi9mjSoiVc5+QeWm2105iyfyfrhHr3is9Tr /21LXs5taOUhUGMi0FWTJFFui0yf+bzKt4SLz8LmDmsTCBDGLg4BWAiKXkM/wxFZW4Jz/8UoXid 9UfDvbuJSVO2tK1ir76xcS9nxic72wMM/xMdiwpXHFH9mMoy6URNYk3DavMDajsefvDo+qXj/G7 tVWYA X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Geliang Tang Now that add_addr_timeout can be dynamically adjusted, there is no need to set specific timeout values in the mptcp_join.sh tests. This patch removes the explicit sysctl settings for net.mptcp.add_addr_timeout from the test scripts. The change simplifies the test setup and ensures the tests work with the default or dynamically adjusted timeout values. Signed-off-by: Geliang Tang Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) --- tools/testing/selftests/net/mptcp/mptcp_join.sh | 3 --- 1 file changed, 3 deletions(-) diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testin= g/selftests/net/mptcp/mptcp_join.sh index 82cae37d9c2026cc55466636d53a76f929a03452..e85bb62046e020dbacbbd44e1f9= e110e1d0104c7 100755 --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh @@ -347,8 +347,6 @@ reset_with_add_addr_timeout() tables=3D"${ip6tables}" fi =20 - ip netns exec $ns1 sysctl -q net.mptcp.add_addr_timeout=3D1 - if ! ip netns exec $ns2 $tables -A OUTPUT -p tcp \ -m tcp --tcp-option 30 \ -m bpf --bytecode \ @@ -2183,7 +2181,6 @@ signal_address_tests() pm_nl_add_endpoint $ns2 10.0.4.2 flags signal =20 # the peer could possibly miss some addr notification, allow retransmiss= ion - ip netns exec $ns1 sysctl -q net.mptcp.add_addr_timeout=3D1 speed=3Dslow \ run_tests $ns1 $ns2 10.0.1.1 =20 --=20 2.50.1 From nobody Wed Sep 17 16:19:50 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 CC42830BBA4; Mon, 1 Sep 2025 09:40:13 +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=1756719613; cv=none; b=Fly6ZD6dTzsJ5hobLfi8U3OsY9nTFHj5+IQnSx5qgTQ/ZSpqCWMZAKuS71V66DGgCMsKuskuMbAPOeyxqXEboezg0Yp2Mzk4e3Pyy3JfFphOlmLjLidtzwskHBjebkrTTE2H34Dz2L/rLPqoaYhNVjaTJrzvxcbVphNkpz0JCFk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756719613; c=relaxed/simple; bh=dTJO1tCQOaPXCW9+vy4vy4eJa6ytua6sNKJ/OHhhNxk=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=giQNQ6nYUR+DEQHc500Ig5bSpuK4mZwCPiA4iFxCNTCq2OYMoV2WlQdEewwh/InvSrpMfXsTXG0YxLfjsBXIvmVL3a84JwsJ/ATquYUvBBwoOCcP5i7oNCTH0rbyaaUOP/dFhbGzaV2nQ86XUzr3Ljjznesj0HkS4LQGqXLy7cA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=usB4Ybyx; 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="usB4Ybyx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6E7D6C4CEF0; Mon, 1 Sep 2025 09:40:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756719613; bh=dTJO1tCQOaPXCW9+vy4vy4eJa6ytua6sNKJ/OHhhNxk=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=usB4Ybyx6nDuZseT+7sTTTH0ygaQIOw2TDRlEZkpWR0W1ijfZyNVma5LphI+fQ90L WaqWnrHGLzqGmqLhIaoP4pMh6KKILTMcGQcRMjV91proCAvYJ7O9nV3fnNQbI4Lg8Q OZhsW0AaLY8FI1Z80oRdw2v+zTY5phad7JIwNUSkq/XzTReJ/2egZF3o4QA4UQmLhC 99Q59lKWjtkCCU5/5499iUM30McfSUZ6acNEUJUZsr9qRwwrr98fP66XvnnliAsWdg Mis4ymigYbvHpqUN2vnKwtBJxoA41trqyGxR0pIB8TVGBPvpYW9n8e/qygKJsMcAJS Zup01X6R5gJIg== From: "Matthieu Baerts (NGI0)" Date: Mon, 01 Sep 2025 11:39:13 +0200 Subject: [PATCH net-next 4/6] selftests: mptcp: add checks for fallback counters Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250901-net-next-mptcp-misc-feat-6-18-v1-4-80ae80d2b903@kernel.org> References: <20250901-net-next-mptcp-misc-feat-6-18-v1-0-80ae80d2b903@kernel.org> In-Reply-To: <20250901-net-next-mptcp-misc-feat-6-18-v1-0-80ae80d2b903@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-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, "Matthieu Baerts (NGI0)" , Gang Yan X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=5270; i=matttbe@kernel.org; h=from:subject:message-id; bh=TFqzr/DMh0lYxvep2tdsVTHnsEaN2pnZvUQretOY304=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGDK2Zr50mXLoTL5jjSTjzdcPzirYtiepTnnt28AiX/Bp5 62Ka7dzOkpZGMS4GGTFFFmk2yLzZz6v4i3x8rOAmcPKBDKEgYtTACbiEsTIcM7f5PKXT6JTkm9+ P1olEZgY7nhgk//BZY9cb5dnGu0//JThv/d/nm3rao76J1UfmFv12F2ya73knjsZ6wJ+vd4dVGK awQkA X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Gang Yan Recently, some mib counters about fallback has been added, this patch provides a method to check the expected behavior of these mib counters during the test execution. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/571 Signed-off-by: Gang Yan Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) --- tools/testing/selftests/net/mptcp/mptcp_join.sh | 123 ++++++++++++++++++++= ++++ 1 file changed, 123 insertions(+) diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testin= g/selftests/net/mptcp/mptcp_join.sh index e85bb62046e020dbacbbd44e1f9e110e1d0104c7..a97b568104bc284f050b2f0e09f= e3fdd3341c5cb 100755 --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh @@ -74,6 +74,17 @@ unset join_create_err unset join_bind_err unset join_connect_err =20 +unset fb_ns1 +unset fb_ns2 +unset fb_infinite_map_tx +unset fb_dss_corruption +unset fb_simult_conn +unset fb_mpc_passive +unset fb_mpc_active +unset fb_mpc_data +unset fb_md5_sig +unset fb_dss + # generated using "nfbpf_compile '(ip && (ip[54] & 0xf0) =3D=3D 0x30) || # (ip6 && (ip6[74] & 0xf0) =3D=3D 0x30)'" CBPF_MPTCP_SUBOPTION_ADD_ADDR=3D"14, @@ -1397,6 +1408,115 @@ chk_join_tx_nr() print_results "join Tx" ${rc} } =20 +chk_fallback_nr() +{ + local infinite_map_tx=3D${fb_infinite_map_tx:-0} + local dss_corruption=3D${fb_dss_corruption:-0} + local simult_conn=3D${fb_simult_conn:-0} + local mpc_passive=3D${fb_mpc_passive:-0} + local mpc_active=3D${fb_mpc_active:-0} + local mpc_data=3D${fb_mpc_data:-0} + local md5_sig=3D${fb_md5_sig:-0} + local dss=3D${fb_dss:-0} + local rc=3D${KSFT_PASS} + local ns=3D$1 + local count + + count=3D$(mptcp_lib_get_counter ${!ns} "MPTcpExtInfiniteMapTx") + if [ -z "$count" ]; then + rc=3D${KSFT_SKIP} + elif [ "$count" !=3D "$infinite_map_tx" ]; then + rc=3D${KSFT_FAIL} + print_check "$ns infinite map tx fallback" + fail_test "got $count infinite map tx fallback[s] in $ns expected $infin= ite_map_tx" + fi + + count=3D$(mptcp_lib_get_counter ${!ns} "MPTcpExtDSSCorruptionFallback") + if [ -z "$count" ]; then + rc=3D${KSFT_SKIP} + elif [ "$count" !=3D "$dss_corruption" ]; then + rc=3D${KSFT_FAIL} + print_check "$ns dss corruption fallback" + fail_test "got $count dss corruption fallback[s] in $ns expected $dss_co= rruption" + fi + + count=3D$(mptcp_lib_get_counter ${!ns} "MPTcpExtSimultConnectFallback") + if [ -z "$count" ]; then + rc=3D${KSFT_SKIP} + elif [ "$count" !=3D "$simult_conn" ]; then + rc=3D${KSFT_FAIL} + print_check "$ns simult conn fallback" + fail_test "got $count simult conn fallback[s] in $ns expected $simult_co= nn" + fi + + count=3D$(mptcp_lib_get_counter ${!ns} "MPTcpExtMPCapableFallbackACK") + if [ -z "$count" ]; then + rc=3D${KSFT_SKIP} + elif [ "$count" !=3D "$mpc_passive" ]; then + rc=3D${KSFT_FAIL} + print_check "$ns mpc passive fallback" + fail_test "got $count mpc passive fallback[s] in $ns expected $mpc_passi= ve" + fi + + count=3D$(mptcp_lib_get_counter ${!ns} "MPTcpExtMPCapableFallbackSYNACK") + if [ -z "$count" ]; then + rc=3D${KSFT_SKIP} + elif [ "$count" !=3D "$mpc_active" ]; then + rc=3D${KSFT_FAIL} + print_check "$ns mpc active fallback" + fail_test "got $count mpc active fallback[s] in $ns expected $mpc_active" + fi + + count=3D$(mptcp_lib_get_counter ${!ns} "MPTcpExtMPCapableDataFallback") + if [ -z "$count" ]; then + rc=3D${KSFT_SKIP} + elif [ "$count" !=3D "$mpc_data" ]; then + rc=3D${KSFT_FAIL} + print_check "$ns mpc data fallback" + fail_test "got $count mpc data fallback[s] in $ns expected $mpc_data" + fi + + count=3D$(mptcp_lib_get_counter ${!ns} "MPTcpExtMD5SigFallback") + if [ -z "$count" ]; then + rc=3D${KSFT_SKIP} + elif [ "$count" !=3D "$md5_sig" ]; then + rc=3D${KSFT_FAIL} + print_check "$ns MD5 Sig fallback" + fail_test "got $count MD5 Sig fallback[s] in $ns expected $md5_sig" + fi + + count=3D$(mptcp_lib_get_counter ${!ns} "MPTcpExtDssFallback") + if [ -z "$count" ]; then + rc=3D${KSFT_SKIP} + elif [ "$count" !=3D "$dss" ]; then + rc=3D${KSFT_FAIL} + print_check "$ns dss fallback" + fail_test "got $count dss fallback[s] in $ns expected $dss" + fi + + return $rc +} + +chk_fallback_nr_all() +{ + local netns=3D("ns1" "ns2") + local fb_ns=3D("fb_ns1" "fb_ns2") + local rc=3D${KSFT_PASS} + + for i in 0 1; do + if [ -n "${!fb_ns[i]}" ]; then + eval "${!fb_ns[i]}" \ + chk_fallback_nr ${netns[i]} || rc=3D${?} + else + chk_fallback_nr ${netns[i]} || rc=3D${?} + fi + done + + if [ "${rc}" !=3D "${KSFT_PASS}" ]; then + print_results "fallback" ${rc} + fi +} + chk_join_nr() { local syn_nr=3D$1 @@ -1482,6 +1602,8 @@ chk_join_nr() join_syn_tx=3D"${join_syn_tx:-${syn_nr}}" \ chk_join_tx_nr =20 + chk_fallback_nr_all + if $validate_checksum; then chk_csum_nr $csum_ns1 $csum_ns2 chk_fail_nr $fail_nr $fail_nr @@ -3334,6 +3456,7 @@ fail_tests() join_csum_ns1=3D+1 join_csum_ns2=3D+0 \ join_fail_nr=3D1 join_rst_nr=3D0 join_infi_nr=3D1 \ join_corrupted_pkts=3D"$(pedit_action_pkts)" \ + fb_ns1=3D"fb_dss=3D1" fb_ns2=3D"fb_infinite_map_tx=3D1" \ chk_join_nr 0 0 0 chk_fail_nr 1 -1 invert fi --=20 2.50.1 From nobody Wed Sep 17 16:19:50 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 3527530FC33; Mon, 1 Sep 2025 09:40:16 +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=1756719617; cv=none; b=Z++r1+AbYTv7rdx3Kqu/vN+YBKwld665uLR1IP5g9LvFYITZMWFh5wOf9Kun1y0fTmc46rZK5EOEKtCpLmaqu3+GXG0e//ZZOr8s6oopCFarPyZw8gnYWY/eqgh84xlRXZgvelLzju0oZVcKU+tKRNtI9a1/ox/iYNHddxy9hN8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756719617; c=relaxed/simple; bh=drdbAkdFpvZAJ6wkGaaJxaCs0z5c3l+uoYeiTtWqED4=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=E29G2pvktZx5aqADI4OU59WvA1FUZw9jFBiIt5PsK5FzDZzoDZBaQdaTNZdCiZGWTlam6q7cAIl1+wJbC97hH1RtaqSCPaFsRvJ5pwEnE7QxFKX4+LqyYXlxVm/UdQkwoGuLXWFaw9JTyjO6Nz3ScL0tcrGveovNr5FTwGt3Qw4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PddF6V6V; 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="PddF6V6V" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C2395C4CEF4; Mon, 1 Sep 2025 09:40:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756719616; bh=drdbAkdFpvZAJ6wkGaaJxaCs0z5c3l+uoYeiTtWqED4=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=PddF6V6VqWIW97vOpKOtwh+Yhp8vXwH53jxVRDQZPAW5XlKfsuh6HzyfJnjG1lwcQ 6reG5E4eVE3zLDmhkA7qyZdaTB7dTNL6SYWadMu00ZHru00y5MMGD3RBYrtY3I3y4r wO+/ax/JQc4CS+djRimqYjSx4S1MtIXP0tJshhzhJKsQ9B4+yb642EqF2b428X0EHT 0YBtZClpBp4awGYO4LpahThYA/sfRxdg91Wm4pmfO3ApK2gj6lR5WDIfe+ifsH9NWg +KEOWYFcprstHVXkAkBNTH33OCn7cIokFqxwA6GU8LSyQG6TWnDSbyWvmHRiNpuH/H GfScABwFMCFUw== From: "Matthieu Baerts (NGI0)" Date: Mon, 01 Sep 2025 11:39:14 +0200 Subject: [PATCH net-next 5/6] net: Add rfs_needed() helper Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250901-net-next-mptcp-misc-feat-6-18-v1-5-80ae80d2b903@kernel.org> References: <20250901-net-next-mptcp-misc-feat-6-18-v1-0-80ae80d2b903@kernel.org> In-Reply-To: <20250901-net-next-mptcp-misc-feat-6-18-v1-0-80ae80d2b903@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-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, "Matthieu Baerts (NGI0)" , Christoph Paasch X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=4310; i=matttbe@kernel.org; h=from:subject:message-id; bh=+SDaulRT9vy5zXdtLFurruXTPo8//MkS7+WIicZWa9E=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGDK2Zr4yy+r+ErUyf26xge3dv1rSLo3bu/+IlM87bMu0V KZ6xV/pjlIWBjEuBlkxRRbptsj8mc+reEu8/Cxg5rAygQxh4OIUgIlov2Rk+LxIQy+j8Vn+ZsvE 2VoXdr7eKpGU3iF7WHF7aeO8rIQX2YwMh0/HvfT/IjlXbGO79mK/g5eKu+7+5Ww5brZBkeemp2I SPwA= X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Christoph Paasch Add a helper to check if RFS is needed or not. Allows to make the code a bit cleaner and the next patch to have MPTCP use this helper to decide whether or not to iterate over the subflows. tun_flow_update() was calling sock_rps_record_flow_hash() regardless of the state of rfs_needed. This was not really a bug as sock_flow_table simply ends up being NULL and thus everything will be fine. This commit here thus also implicitly makes tun_flow_update() respect the state of rfs_needed. Suggested-by: Matthieu Baerts Signed-off-by: Christoph Paasch Acked-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) --- include/net/rps.h | 85 ++++++++++++++++++++++++++++++++++++---------------= ---- 1 file changed, 56 insertions(+), 29 deletions(-) diff --git a/include/net/rps.h b/include/net/rps.h index 9917dce42ca457e9c25d9e84ee450235f771d09b..f1794cd2e7fb32a36bde9959fab= 651663ab190fd 100644 --- a/include/net/rps.h +++ b/include/net/rps.h @@ -85,11 +85,8 @@ static inline void rps_record_sock_flow(struct rps_sock_= flow_table *table, WRITE_ONCE(table->ents[index], val); } =20 -#endif /* CONFIG_RPS */ - -static inline void sock_rps_record_flow_hash(__u32 hash) +static inline void _sock_rps_record_flow_hash(__u32 hash) { -#ifdef CONFIG_RPS struct rps_sock_flow_table *sock_flow_table; =20 if (!hash) @@ -99,42 +96,33 @@ static inline void sock_rps_record_flow_hash(__u32 hash) if (sock_flow_table) rps_record_sock_flow(sock_flow_table, hash); rcu_read_unlock(); -#endif } =20 -static inline void sock_rps_record_flow(const struct sock *sk) +static inline void _sock_rps_record_flow(const struct sock *sk) { -#ifdef CONFIG_RPS - if (static_branch_unlikely(&rfs_needed)) { - /* Reading sk->sk_rxhash might incur an expensive cache line - * miss. - * - * TCP_ESTABLISHED does cover almost all states where RFS - * might be useful, and is cheaper [1] than testing : - * IPv4: inet_sk(sk)->inet_daddr - * IPv6: ipv6_addr_any(&sk->sk_v6_daddr) - * OR an additional socket flag - * [1] : sk_state and sk_prot are in the same cache line. + /* Reading sk->sk_rxhash might incur an expensive cache line + * miss. + * + * TCP_ESTABLISHED does cover almost all states where RFS + * might be useful, and is cheaper [1] than testing : + * IPv4: inet_sk(sk)->inet_daddr + * IPv6: ipv6_addr_any(&sk->sk_v6_daddr) + * OR an additional socket flag + * [1] : sk_state and sk_prot are in the same cache line. + */ + if (sk->sk_state =3D=3D TCP_ESTABLISHED) { + /* This READ_ONCE() is paired with the WRITE_ONCE() + * from sock_rps_save_rxhash() and sock_rps_reset_rxhash(). */ - if (sk->sk_state =3D=3D TCP_ESTABLISHED) { - /* This READ_ONCE() is paired with the WRITE_ONCE() - * from sock_rps_save_rxhash() and sock_rps_reset_rxhash(). - */ - sock_rps_record_flow_hash(READ_ONCE(sk->sk_rxhash)); - } + _sock_rps_record_flow_hash(READ_ONCE(sk->sk_rxhash)); } -#endif } =20 -static inline void sock_rps_delete_flow(const struct sock *sk) +static inline void _sock_rps_delete_flow(const struct sock *sk) { -#ifdef CONFIG_RPS struct rps_sock_flow_table *table; u32 hash, index; =20 - if (!static_branch_unlikely(&rfs_needed)) - return; - hash =3D READ_ONCE(sk->sk_rxhash); if (!hash) return; @@ -147,6 +135,45 @@ static inline void sock_rps_delete_flow(const struct s= ock *sk) WRITE_ONCE(table->ents[index], RPS_NO_CPU); } rcu_read_unlock(); +} +#endif /* CONFIG_RPS */ + +static inline bool rfs_is_needed(void) +{ +#ifdef CONFIG_RPS + return static_branch_unlikely(&rfs_needed); +#else + return false; +#endif +} + +static inline void sock_rps_record_flow_hash(__u32 hash) +{ +#ifdef CONFIG_RPS + if (!rfs_is_needed()) + return; + + _sock_rps_record_flow_hash(hash); +#endif +} + +static inline void sock_rps_record_flow(const struct sock *sk) +{ +#ifdef CONFIG_RPS + if (!rfs_is_needed()) + return; + + _sock_rps_record_flow(sk); +#endif +} + +static inline void sock_rps_delete_flow(const struct sock *sk) +{ +#ifdef CONFIG_RPS + if (!rfs_is_needed()) + return; + + _sock_rps_delete_flow(sk); #endif } =20 --=20 2.50.1 From nobody Wed Sep 17 16:19:50 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 840663101DB; Mon, 1 Sep 2025 09:40:20 +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=1756719620; cv=none; b=ernCfy9/XlfGGcJ8vB+c4ll8HEASY8lM2E8lcz49yy6ibMgpzjDiFYWjFA0udm7gLqkZ4w7smP9JFDMxPcVWYjvYtITATpJB+FmTCjSb4engowsNkACMD0BJ1HukGOFazh5oQvpKWLQaJX2vqCVUWpsLx9B5zw/orE3wuShILoc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756719620; c=relaxed/simple; bh=xXUKa/ahfEA+dPigVdk1wYHJYq2Hcf1En5xC3FDAHjM=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=Gwd2lgS50WOnof/kqvGKC7HmbGa0Iclq4ocQYzoxaxdm5fCq7I1K88XedNSaJ3YJ+5Xb/ltCu7tkK4MSCUj/768DiDZfQcI3ySoGfJwpZkUTt1VNSA4d5DUCcVjGqmHU+dZB0/WZLtcVa2NweUmTWY3a7Lo+L+zpAVpgY+satCo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rjQ0rv7+; 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="rjQ0rv7+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 21B93C4CEF7; Mon, 1 Sep 2025 09:40:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756719620; bh=xXUKa/ahfEA+dPigVdk1wYHJYq2Hcf1En5xC3FDAHjM=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=rjQ0rv7+GecG8W/iYX14MaA2yBXstI7q3rKUFQ66j7uBiWVR31v1sluzWxo0WYj3E GCPaHBNB78gf8ExRdW8sSFk9ySZhU2cludGgYO2GOfD8uXckj6ne/mnpOi3I6KunRn 51C/IP9brrZ1MP0a1SfKeAMA5kLjTaSe2h48TGApvNuAp62zKYq8RDhSbEo46dDziC G9kx66wYKHuq5f9m5zQyT5GH3Kdv0gqRdYZ5eoXlaw45tG6aTEtAn6It1fskyhHE/U PB0mDZ0wR+FNv+3fphW0lYYbO5MrOCMC4iB6KWiI8ivU2xb1drVpYGf/Hh4LqVGgnY OfyQXpCX+8kvA== From: "Matthieu Baerts (NGI0)" Date: Mon, 01 Sep 2025 11:39:15 +0200 Subject: [PATCH net-next 6/6] mptcp: record subflows in RPS table Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250901-net-next-mptcp-misc-feat-6-18-v1-6-80ae80d2b903@kernel.org> References: <20250901-net-next-mptcp-misc-feat-6-18-v1-0-80ae80d2b903@kernel.org> In-Reply-To: <20250901-net-next-mptcp-misc-feat-6-18-v1-0-80ae80d2b903@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-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, "Matthieu Baerts (NGI0)" , Christoph Paasch X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=2920; i=matttbe@kernel.org; h=from:subject:message-id; bh=FVq/DLjkSiShyfNhu4andsIboYNo8KQGQUci1ShMrjQ=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGDK2Zr5JihI/W+L0RoHdca+w9oaamE9iKa9LBfNNXrXWT eR/vlu2o5SFQYyLQVZMkUW6LTJ/5vMq3hIvPwuYOaxMIEMYuDgFYCI2Nxj+Cv5N73Bx1OaVsvLc s/RQTum6yqms0qkm09pvdh+RSnbQZWTo6GPbVFH5WNMmK2P+J9mcpm8ZfxobdH8tuKBy4LLCcls mAA== X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Christoph Paasch Accelerated Receive Flow Steering (aRFS) relies on sockets recording their RX flow hash into the rps_sock_flow_table so that incoming packets are steered to the CPU where the application runs. With MPTCP, the application interacts with the parent MPTCP socket while data is carried over per-subflow TCP sockets. Without recording these subflows, aRFS cannot steer interrupts and RX processing for the flows to the desired CPU. Record all subflows in the RPS table by calling sock_rps_record_flow() for each subflow at the start of mptcp_sendmsg(), mptcp_recvmsg() and mptcp_stream_accept(), by using the new helper mptcp_rps_record_subflows(). It does not by itself improve throughput, but ensures that IRQ and RX processing are directed to the right CPU, which is a prerequisite for effective aRFS. Signed-off-by: Christoph Paasch Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/protocol.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index ad41c48126e44fda646f1ec1c81957db1407a6cc..a8d57b88578dfea807d3d55e430= 849aa8005c637 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -12,6 +12,7 @@ #include #include #include +#include #include #include #include @@ -1740,6 +1741,20 @@ static u32 mptcp_send_limit(const struct sock *sk) return limit - not_sent; } =20 +static void mptcp_rps_record_subflows(const struct mptcp_sock *msk) +{ + struct mptcp_subflow_context *subflow; + + if (!rfs_is_needed()) + return; + + mptcp_for_each_subflow(msk, subflow) { + struct sock *ssk =3D mptcp_subflow_tcp_sock(subflow); + + sock_rps_record_flow(ssk); + } +} + static int mptcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t len) { struct mptcp_sock *msk =3D mptcp_sk(sk); @@ -1753,6 +1768,8 @@ static int mptcp_sendmsg(struct sock *sk, struct msgh= dr *msg, size_t len) =20 lock_sock(sk); =20 + mptcp_rps_record_subflows(msk); + if (unlikely(inet_test_bit(DEFER_CONNECT, sk) || msg->msg_flags & MSG_FASTOPEN)) { int copied_syn =3D 0; @@ -2131,6 +2148,8 @@ static int mptcp_recvmsg(struct sock *sk, struct msgh= dr *msg, size_t len, goto out_err; } =20 + mptcp_rps_record_subflows(msk); + timeo =3D sock_rcvtimeo(sk, flags & MSG_DONTWAIT); =20 len =3D min_t(size_t, len, INT_MAX); @@ -3922,6 +3941,8 @@ static int mptcp_stream_accept(struct socket *sock, s= truct socket *newsock, mptcp_sock_graft(ssk, newsock); } =20 + mptcp_rps_record_subflows(msk); + /* Do late cleanup for the first subflow as necessary. Also * deal with bad peers not doing a complete shutdown. */ --=20 2.50.1