Re: [RFC PATCH mptcp-next v3 2/3] mptcp: pm: kernel: retry subflows closed after an error

[Matthieu Baerts <matttbe@kernel.org>]

Hi Anil,

I noticed new versions, but I don't know if you saw my reply here. Do
you mind replying to my previous questions / comments here below, please?

On 16/10/2026 10:43, Matthieu Baerts wrote:
> Hi Anil,
> 
> Thank you for your reply.
> 
> On 16/10/2026 07:49, Anil Kaushik wrote:
>>> Add a sensible default value (what do you recommend?)
>>
>> 15 SYN retries: about 20 minutes with the 120s max RTO.
> 
> I guess it could even be longer, no? With an exponential backoff, it's
> not spamming the network too much.
> 
> I wonder if we shouldn't get something similar to tcp_retries2. But
> here, with the syn, we also need to tcp_syn_linear_timeouts into
> account. Either we keep it to 15 by default and, (if not 0), we add
> tcp_syn_linear_timeouts, or we initialise it to 19.
> 
>>> modify icsk_syn_retries instead [...] WDYT?
>>
>> Good idea, I will do that: one new subflow per failure, with its SYN
>> retries set from the new netlink limit, 0 = disabled. It also removes
>> the socket reuse, the retries counter and the 60s check.
>>
>> One point to think though, If ICMP unreachable stops the SYN at once.
>> I would not retry
>> again then. Is that OK?
> 
> Good point. In your specific case, what do you observe?
> 
> To me, the best is to have the network manager (something from
> userspace) removing the MPTCP endpoints when they are not "usable", but
> here it can be specific to the destination. I would then say to look at
> this case later. In this case, we could eventually disconnect the
> subflow, and add a timer to retry later. But that's also more prone to
> bugs, so if we can avoid that, probably better to!
> 
>>> Do we have other similar ones? [...] ss -Mte, would that work?
>>
>> I will drop the MIB counter. The test can use the MPJ counters and the
>> netlink events.
> 
> Thanks! You can expose the new limit in "struct mptcp_info", instead of
> "reserved".
> 
>>> Is it specific for your case?
>>
>> No, it came from a Sashiko review: a dead subflow waiting to be closed
>> could be re-created after its endpoint or the peer's address was
>> removed. I will try to move it to pm_kernel.c.
> 
> What did you end-up doing for this?
> 
>>> can we not check why it failed instead?
>>
>> With your idea it is not needed: only one retry, nothing to count.
> 
> Good
> 
>>> what error do you get when the issue is detected via TCP Keepalive?
>>
>> ETIMEDOUT, so it is retried.
> 
> Thanks!
> 
>>> Why can we not always re-used?
>>
>> A subflow that carried data needs the full close cleanup. With your
>> idea we always create a new subflow, so there is only one path.
>>
>> For the rest: OK. I will go through pm.c, avoid struct holes and
>> duplicated connect code, drop the RFC tag, add a changelog per patch,
>> and test closing the connection while retrying plus the netlink events.
>> I will wait for the netdev Sashiko review before sending.
> 
> Thanks! BTW, it is easier if you reply inline here below, to keep the
> context:
> 
> https://subspace.kernel.org/etiquette.html#do-not-top-post-when-replying
> 
>> On Wed, Oct 14, 2026 at 11:43 PM Matthieu Baerts <matttbe@kernel.org> wrote:
> (...)
> 
> Cheers,
> Matt

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