The limits have been recently increased, it is required to validate that
having 64 subflows is allowed.

Here, both the client and the server have 8 network interfaces. The
server has 8 endpoints marked as 'signal' to announce all its v4
addresses. The client also has 8 endpoints, but marked as 'subflow' and
'fullmesh' in order to create 8 subflows to each address announced by
the server. This means 63 additional subflows will be created after the
initial one.

If it is not possible to increase the limits to 64, it means an older
kernel version is being used, and the test is skipped.

Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
 tools/testing/selftests/net/mptcp/mptcp_join.sh | 28 +++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh
index 28da9df797ae..c6bb345d056b 100755
--- a/tools/testing/selftests/net/mptcp/mptcp_join.sh
+++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh
@@ -513,6 +513,19 @@ reset_with_tcp_filter()
 	fi
 }
 
+# For kernel supporting limits above 8
+# $1: title ; $2,4: addrs limit ns1,2 ; $3,5: subflows limit ns1,2
+reset_with_high_limits()
+{
+	reset "${1}" || return 1
+
+	if ! pm_nl_set_limits "${ns1}" "${2}" "${3}" 2>/dev/null ||
+	   ! pm_nl_set_limits "${ns2}" "${4}" "${5}" 2>/dev/null; then
+		mark_as_skipped "unable to set the limits to ${*:2}"
+		return 1
+	fi
+}
+
 # $1: err msg
 fail_test()
 {
@@ -3670,6 +3683,21 @@ fullmesh_tests()
 		chk_prio_nr 0 1 1 0
 		chk_rm_nr 0 1
 	fi
+
+	# fullmesh in 8x8 to create 63 additional subflows
+	if ifaces_nr=8 reset_with_high_limits "fullmesh 8x8" 64 64 64 64; then
+		# higher chance to lose ADD_ADDR: allow retransmissions
+		ip netns exec $ns1 sysctl -q net.mptcp.add_addr_timeout=1
+		local i
+		for i in $(seq 1 8); do
+			pm_nl_add_endpoint $ns2 10.0.$i.2 flags subflow,fullmesh
+			pm_nl_add_endpoint $ns1 10.0.$i.1 flags signal
+		done
+		speed=slow \
+			run_tests $ns1 $ns2 10.0.1.1
+		chk_join_nr 63 63 63
+	fi
+
 }
 
 fastclose_tests()

-- 
2.53.0

On Wed, 15 Apr 2026, Matthieu Baerts (NGI0) wrote:

> The limits have been recently increased, it is required to validate that
> having 64 subflows is allowed.
>
> Here, both the client and the server have 8 network interfaces. The
> server has 8 endpoints marked as 'signal' to announce all its v4
> addresses. The client also has 8 endpoints, but marked as 'subflow' and
> 'fullmesh' in order to create 8 subflows to each address announced by
> the server. This means 63 additional subflows will be created after the
> initial one.
>
> If it is not possible to increase the limits to 64, it means an older
> kernel version is being used, and the test is skipped.
>

Does this have much of an impact on total time for the tests? Would it be 
worthwhile to test the larger limits on kernels that can handle it, and 
run the existing tests on older kernels?

In other words, the larger limit test seems to have redundant coverage 
with some older tests, so maybe skip the redundant tests on new kernels.

- Mat

> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
> ---
> tools/testing/selftests/net/mptcp/mptcp_join.sh | 28 +++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh
> index 28da9df797ae..c6bb345d056b 100755
> --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh
> +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh
> @@ -513,6 +513,19 @@ reset_with_tcp_filter()
> 	fi
> }
>
> +# For kernel supporting limits above 8
> +# $1: title ; $2,4: addrs limit ns1,2 ; $3,5: subflows limit ns1,2
> +reset_with_high_limits()
> +{
> +	reset "${1}" || return 1
> +
> +	if ! pm_nl_set_limits "${ns1}" "${2}" "${3}" 2>/dev/null ||
> +	   ! pm_nl_set_limits "${ns2}" "${4}" "${5}" 2>/dev/null; then
> +		mark_as_skipped "unable to set the limits to ${*:2}"
> +		return 1
> +	fi
> +}
> +
> # $1: err msg
> fail_test()
> {
> @@ -3670,6 +3683,21 @@ fullmesh_tests()
> 		chk_prio_nr 0 1 1 0
> 		chk_rm_nr 0 1
> 	fi
> +
> +	# fullmesh in 8x8 to create 63 additional subflows
> +	if ifaces_nr=8 reset_with_high_limits "fullmesh 8x8" 64 64 64 64; then
> +		# higher chance to lose ADD_ADDR: allow retransmissions
> +		ip netns exec $ns1 sysctl -q net.mptcp.add_addr_timeout=1
> +		local i
> +		for i in $(seq 1 8); do
> +			pm_nl_add_endpoint $ns2 10.0.$i.2 flags subflow,fullmesh
> +			pm_nl_add_endpoint $ns1 10.0.$i.1 flags signal
> +		done
> +		speed=slow \
> +			run_tests $ns1 $ns2 10.0.1.1
> +		chk_join_nr 63 63 63
> +	fi
> +
> }
>
> fastclose_tests()
>
> -- 
> 2.53.0
>
>
>

Hi Mat,

On 18/04/2026 20:22, Mat Martineau wrote:
> On Wed, 15 Apr 2026, Matthieu Baerts (NGI0) wrote:
> 
>> The limits have been recently increased, it is required to validate that
>> having 64 subflows is allowed.
>>
>> Here, both the client and the server have 8 network interfaces. The
>> server has 8 endpoints marked as 'signal' to announce all its v4
>> addresses. The client also has 8 endpoints, but marked as 'subflow' and
>> 'fullmesh' in order to create 8 subflows to each address announced by
>> the server. This means 63 additional subflows will be created after the
>> initial one.
>>
>> If it is not possible to increase the limits to 64, it means an older
>> kernel version is being used, and the test is skipped.
>>
> 
> Does this have much of an impact on total time for the tests? Would it
> be worthwhile to test the larger limits on kernels that can handle it,
> and run the existing tests on older kernels?
> 
> In other words, the larger limit test seems to have redundant coverage
> with some older tests, so maybe skip the redundant tests on new kernels.

Good point. In terms of time, like most tests there, it waits for the
whole transfer, so the same time as other 'speed=slow' tests.

Surprisingly, we didn't have similar tests before setting multiple
'signal' endpoints on the server side, and multiple 'subflow + fullmesh'
on the client side. It was either one or the other. Plus we didn't check
with subflows up the previous limit (8), it was max 5. So no redundancy
here, I think. Or we disable the simple ones focussing on the client and
server side separately? (but then it no longer validates that on older
kernels)

Note that this test helped me find the issue that led to "mptcp: pm:
ADD_ADDR rtx: resched blocked ADD_ADDR quicker", which led to most of
the other Fixes patches :)

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

On Mon, 20 Apr 2026, Matthieu Baerts wrote:

> Hi Mat,
>
> On 18/04/2026 20:22, Mat Martineau wrote:
>> On Wed, 15 Apr 2026, Matthieu Baerts (NGI0) wrote:
>>
>>> The limits have been recently increased, it is required to validate that
>>> having 64 subflows is allowed.
>>>
>>> Here, both the client and the server have 8 network interfaces. The
>>> server has 8 endpoints marked as 'signal' to announce all its v4
>>> addresses. The client also has 8 endpoints, but marked as 'subflow' and
>>> 'fullmesh' in order to create 8 subflows to each address announced by
>>> the server. This means 63 additional subflows will be created after the
>>> initial one.
>>>
>>> If it is not possible to increase the limits to 64, it means an older
>>> kernel version is being used, and the test is skipped.
>>>
>>
>> Does this have much of an impact on total time for the tests? Would it
>> be worthwhile to test the larger limits on kernels that can handle it,
>> and run the existing tests on older kernels?
>>
>> In other words, the larger limit test seems to have redundant coverage
>> with some older tests, so maybe skip the redundant tests on new kernels.
>
> Good point. In terms of time, like most tests there, it waits for the
> whole transfer, so the same time as other 'speed=slow' tests.
>
> Surprisingly, we didn't have similar tests before setting multiple
> 'signal' endpoints on the server side, and multiple 'subflow + fullmesh'
> on the client side. It was either one or the other. Plus we didn't check
> with subflows up the previous limit (8), it was max 5. So no redundancy
> here, I think. Or we disable the simple ones focussing on the client and
> server side separately? (but then it no longer validates that on older
> kernels)

My concern was mostly the runtime of the tests. It sounds like the 
redundancy (if any) is with some simple tests that probably don't take 
long, so it's not worth complicating the test logic and having "only for 
old kernel" tests that would be at greater risk of getting stale. So, no 
need to change this patch.

- Mat