Re: [PATCH mptcp-net v5 17/20] selftests: mptcp: join: validate 8x8 subflows

[Matthieu Baerts <matttbe@kernel.org>]

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.