Route to v5.10 LTS

[arter97]

Now that the new LTS kernel is out, I'm wondering what's in plan for out-of-tree MPTCP.

Before MPTCP went upstream, it was relatively trivial to merge out-of-tree MPTCP support to v5.4(#372). Now that the upstream has bits of MPTCP itself, I assume it's not as trivial to merge out-of-tree MPTCP on top of v5.10.

Are there any plans for v5.10's out-of-tree MPTCP?

Maybe it's a weak argument, but I want to use out-of-tree version for performance( https://github.com/multipath-tcp/mptcp_net-next/wiki ) as my use-case primarily concerns MPTCP and not regular TCP.

Thanks!

[matttbe]

Hi,

The current plan is to stabilise mptcp_trunk which is on v5.4 and create a new stable branch (MPTCP 0.96).

But the global priority is to work on the upstream version. Ideally, v5.4 would be the last LTS this out-of-tree kernel would need to support because we will have more conflicts to switch to the v5.10. But if there is a need and people that can work on supporting the v5.10, we might support it at some points.

Do you have specific features from v5.10, not available in v5.4?

Cheers, Matt

[arter97]

Hi.

It's just that v5.4 is showing its age in general. I used to backport drivers if v5.4 didn't have it or needed an upgrade, but something like io_uring is really hard to backport and we're looking into using io_uring to improve some NVMe I/O bottleneck(that just happens to run along side MPTCP).

Moving to the mainline's MPTCP implementation doesn't seem to be quite straight forward as well.

We configured our server from https://multipath-tcp.org/pmwiki.php/Users/ConfigureRouting and using mainline's MPTCP just broke it and we weren't able to find guides online on how to use mainline MPTCP or MPTCP v1 properly.

We configured the server from mptcp_v0.95 and later migrated to v5.4, and MPTCP was (mostly) fine for almost 2 years now. Upgrading to v5.4 was painless and it didn't need any configuration changes. I'm not quite sure what we're supposed to do to migrate to mainline's implementation.

Thanks.

[matttbe]

There are two different possibilities here.

• We can always have this out-of-tree fork supporting new Linux LTS releases but this work needs to be done. I guess that this will be done only if there is a real need. Anybody can have a look but if someone wants his/her work to be accepted, best is to do a merge for each Linux version (5.5, 5.6, etc.) and resolve each conflict in separated commit with an explanation to make the review possible.
• Or focus on the upstream version and fix what needs to be fixed or add required features. For the moment, only MPTCPv1 is supported with the mainline kernel. We could also imagine supporting MPTCPv0 if it is accepted or have that in a fork with reduced maintenance compared to a quite different implementation like we have here.

Maintaining this out-of-tree kernel has a cost which is justified for the moment. Supporting a new LTS kernel is something we would like to avoid. But it doesn't mean we will not support it at some point.

[arter97]

That is very understandable.

Porting something to different version of Linux, both back and forward is quite painful especially if it's rooted deeply into a Linux's subsystem.

Would it be reasonable to ask how to migrate from MPTCPv0 to v1? Unless I'm doing something wrong, it seems like it's intended that v1 isn't a drop-in replacement from v0.

I'm willing try out v1 and see if there's a room for improvement in my use-case :)

Thanks.

[matttbe]

Would it be reasonable to ask how to migrate from MPTCPv0 to v1? Unless I'm doing something wrong, it seems like it's intended that v1 isn't a drop-in replacement from v0.

Indeed, you need both the client and the server to support the same version. For the moment, stable versions of the out-of-tree kernel only support v0 while in the mainline kernel, only v1 is supported. (mptcp_trunk branch is supporting v1 but still in development.)

So switching from v0 to v1 simply means upgrading to a recent kernel on both side or switch to mptcp_trunk branch :)

https://github.com/multipath-tcp/mptcp_net-next/wiki#mptcpv0-vs-mptcpv1

I'm willing try out v1 and see if there's a room for improvement in my use-case :)

Good idea!

[arter97]

I've opened a new issue describing our use case #406

Using v5.10 kernel on both server/client doesn't use MPTCP as described in #406.

[matttbe]

Note that if v5.4 is not maintained for more than 2 years, it might force some of us to switch to v5.10: https://lore.kernel.org/lkml/YBBkplRxzzmPYKC+@kroah.com/

[teto]

on a related note, I see there is a 0.96 branch but no 0.96 tag. Is it because 0.96 is not considered stable yet ? are we going to see a tag ? I thought of packaging it for nixos but I wanted to confirm the status of that version first.

[matttbe]

the idea was to tag it when #427 would be fixed but we need someone to look at that.

[suyuan168]

hi The best cooperation I can guide MPTCP is openwrt. Of course it is best to use it as a router. Now many cores of openwrt master are switching to 5.10. So I think it is necessary to support 5.10.

[suyuan168]

5.15 | Greg Kroah-Hartman & Sasha Levin | 2021-10-31 | Oct, 2023 5.10 | Greg Kroah-Hartman & Sasha Levin | 2020-12-13 | Dec, 2026 5.4 | Greg Kroah-Hartman & Sasha Levin | 2019-11-24 | Dec, 2025 4.19 | Greg Kroah-Hartman & Sasha Levin | 2018-10-22 | Dec, 2024 4.14 | Greg Kroah-Hartman & Sasha Levin | 2017-11-12 | Jan, 2024 4.9 | Greg Kroah-Hartman & Sasha Levin | 2016-12-11 | Jan, 2023 4.4 | Greg Kroah-Hartman & Sasha Levin | 2016-01-10 | Feb, 2022