Re: [PATCH mptcp-net v2 2/2] selftests: mptcp: join: retry connect after early fallback

[Matthieu Baerts <matttbe@kernel.org>]

On 12/09/2026 10:42, quanyeyang wrote:
> On Friday, September 11th, 2026 at AM 10:20, Matthieu Baerts <matttbe@kernel.org> wrote:
>  
>> Thank you for this test, but we cannot accept this: it is good to have a
>> test linked to a fix or a feature, but it has to be maintainable. If
>> each fix/feature adds 300+ LoC, that's unmaintainable (or LLM become
>> mandatory for that, but that's not what we want: we still need to be
>> able to read the test).
>>
>> Ideally:
>>
>> - create a small packetdrill test instead, using the MPTCP version [1]
>>
>> - not everything can be tested with packetdrill (even if it can also be
>>   extended) and adding code in the selftests is OK, but, if possible, it
>>   should reuse the existing tools and helpers
>>
>> So in this case here: can you have a packetdrill test instead? It should
>> be possible, no? If not, can you only use 'mptcp_connect' and the
>> existing helpers from mptcp_join.sh?
>>
>> Also, mptcp_join.sh is to validate cases with multiple subflows. I don't
>> think you need that, right?
>>
>> [1] https://github.com/multipath-tcp/packetdrill/
>>
>> Cheers,
>> Matt
>> --
>> Sponsored by the NGI0 Core fund.
>>
>>
> Thanks for the detailed guidance.
> Agreed, 2/2 is too heavy. I will drop it and try to add a small packetdrill
> script under gtests/net/mptcp/regressions/ instead: record a blackhole,
> then fail connect() on the same fd before SS_CONNECTING, clear
> blackhole_timeout, and check the retry still sends MP_CAPABLE
> (TCP_IS_MPTCP / the 3rd ACK).

Thanks, I think it should be easier and clearer to do that with packetdrill.

> The kernel fix in v2 1/2 does not depend on that selftest. Could you
> apply that one on its own?
I can, but I prefer to have the new test first, to validate it with and
without the modification.

In other words, no need to resend patch 1.

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