Re: [PATCH mptcp-next v3] mptcp: honour configured min/max RTO in retransmit paths

[Matthieu Baerts <matttbe@kernel.org>]

Hi Kalpan,

On 03/08/2026 06:52, Kalpan Jani wrote:
> Hi all,
> 
> Gentle ping on this v3, sent on 2026-06-17:-
> 
>   https://lore.kernel.org/all/20260617114508.253716-1-kalpan.jani@mpiricsoftware.com/

Sorry, thank you for your patience. The priority is on the fixes, and we
are trying to go through all patches when we can. But I admit is way
longer than usual.

> I didn't get any CI results or review comments on it, so I want to
> make sure it didn't get lost somewhere. As far as I can tell it was
> sent to the right list with the right prefix.

It looks like the CI didn't manage to send the notification. I restarted it.

It looks like the AI review was available:


https://sashiko.dev/#/patchset/20260617114508.253716-1-kalpan.jani%40mpiricsoftware.com

I guess at least the commit message should be updated, because the MPTCP
sockets do not perform routing lookups. It could only do it when a
subflow has been selected, which is not the case in the cases you
modified. Same for the socket option: it is not available yet.

Also, maybe better to directly use icsk_rto_{min,max} to avoid
confusions, no? By doing that, you can remove the exception for "ip
route ... rto_min 0" that doesn't influence anything here anyway from
what I understood.

> Happy to rebase and resend as v4 if that is easier, or to rework it
> if this isn't the approach you'd like for issue #618.

It would be good to have a validation for this. Because it is
time-sensitive, the easier would be to do it with Packetdrill. Here, no
need to create a new one, simply extend existing ones, e.g.
mptcp/dss/dss_fin_retrans_* → we could set the tcp_rto_max_ms sysctl to
have a shorter time, no? If at least one test is modified to validate
your modifications in mptcp_set_datafin_timeout(), that would be good.

WDYT?

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