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

Hi Matt,

Thanks for taking a look.

> 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.

Ah right, I missed that. So effectively only the two sysctls matter here,
since that's what gets seeded in __mptcp_init_sock(). I'll fix the commit
message to say that, and drop the claims about the route metric and the
socket options.

> 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.

Yes, makes sense. That also gets rid of the __mptcp_init_sock() special
case I added in v2 for the lockdep splat, so everything reads the icsk
fields the same way. And agreed the rto_min 0 check can go, the sysctl
can't go below 1us anyway.

I'd still keep the max_t(..., 1) inside the ilog2() though: nothing
stops someone from setting tcp_rto_min_us higher than tcp_rto_max_ms
(they're validated separately), and then rto_max / rto_min is 0. I'll
add a comment for that.

> 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.

Good idea. I'll try with tcp_rto_max_ms=3D1000 (the minimum) in
dss_fin_retrans_established.pkt: with the default rto_min that caps the
shift at ilog2(5) =3D 2, so the intervals should stop doubling after
~800ms. The current test only checks 3 retransmissions and the
divergence should be on the 4th one, so I'll extend it a bit and check
it fails on a kernel without the patch. Packetdrill patch to follow
separately.

Will send a v4 with all that if it sounds good to you.

Cheers,
Kalpan Jani


From: Matthieu Baerts <[email protected]>
To: "Kalpan Jani"<[email protected]>, "mptcp"<[email protected]=
x.dev>
Cc: "martineau"<[email protected]>, "pabeni"<[email protected]>, "shardu=
l.b"<[email protected]>, "janak"<[email protected]>, "kalpanjani00=
9"<[email protected]>, "Lixiasong1"<[email protected]>
Date: Mon, 03 Aug 2026 23:04:58 +0530
Subject: Re: [PATCH mptcp-next v3] mptcp: honour configured min/max RTO in =
retransmit paths

 > Hi Kalpan,
 >=20
 > On 03/08/2026 06:52, Kalpan Jani wrote:
 > > Hi all,
 > >=20
 > > Gentle ping on this v3, sent on 2026-06-17:-
 > >=20
 > >   https://lore.kernel.org/all/20260617114508.253716-1-kalpan.jani@mpir=
icsoftware.com/
 >=20
 > 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.
 >=20
 > > 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.
 >=20
 > It looks like the CI didn't manage to send the notification. I restarted=
 it.
 >=20
 > It looks like the AI review was available:
 >=20
 >=20
 > https://sashiko.dev/#/patchset/20260617114508.253716-1-kalpan.jani%40mpi=
ricsoftware.com
 >=20
 > 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.
 >=20
 > 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.
 >=20
 > > 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.
 >=20
 > 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_* =E2=86=92 we could set the tcp_rto_max_ms sy=
sctl 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.
 >=20
 > WDYT?
 >=20
 > Cheers,
 > Matt
 > --=20
 > Sponsored by the NGI0 Core fund.
 >=20
 >=20