[arch-dev-public] Bringing Multipath TCP kernel (linux-mptcp) to [community]
baptiste at bitsofnetworks.org
Sat Jun 10 22:47:07 UTC 2017
On Wed, Jun 07, 2017 at 08:55:15AM -1000, Gaetan Bisson wrote:
> [2017-06-06 22:58:01 +0200] Baptiste Jonglez:
> > Since a few years, I maintain a variant of the linux kernel in the AUR 
> > that adds support for Multipath TCP . The most recent version is based
> > on linux 4.4, and the package I maintain tries to follow the "linux"
> > package from [core] as much as possible.
> > There is no short- or medium-term perspective to merge Multipath TCP
> > upstream, so I would like to bring this package to [community]. There are
> > already several kernel variants in the official repos, but I would like to
> > get some feedback before adding another one.
> We already have an official linux package in [core] which is very well
> maintained and works great for 99% of our users, so I'd really like if
> you tried to explain why we need another variant and why the AUR is not
> suitable for it anymore.
At that point, Multipath TCP is mostly useful to researchers and
tinkerers, because both ends of a TCP connection need to run the modified
kernel (otherwise, it just falls back to regular TCP).
However, I still think it would be useful in [community]:
1) One nice use-case is link aggregation, where you basically tunnel
traffic over a Multipath TCP connection. You may want to build such a
tunnelling system with Arch.
2) Not everybody has the resources to build a kernel (time, CPU, memory, disk...)
3) It is good to have kernel diversity in our repositories. For instance,
I had a laptop that couldn't go to sleep with the kernels from [core]
(either linux or linux-lts), but it worked with linux-mptcp. This is
really not the main goal of having linux-mptcp in [community], but it's
a nice side-effect.
By the way, the kernel is completely stable, I have been using it on a
daily basis (on my laptop) since a few years. At the beginning of the
project in ~2014, there were occasional kernel panics, but not anymore.
> As you're aware, we've had another package (linux-grsec) with a user
> base certainly much larger than linux-multipath come and go because
> upstream went another direction and nobody had the resources to fork it.
> I'd really like our packages to enjoy some level of support and not just
> go to [community] "because they can" and get dropped just as fast. What
> could you tell us about linux-multipath on that front?
When talking about "some level of support", do you mean whether the
upstream project is active?
The project has one main developer, 2 to 3 additional developers, and
several small contributors (including myself). I think nobody is working
full-time on it, though.
Regarding activity, major releases happen when the project is rebased on a
more recent kernel version and sufficiently tested:
- v0.86 released 2013-03-07, based on linux 3.5
- v0.87 released 2013-07-25, based on linux 3.10
- v0.88 released 2013-10-30, based on linux 3.11
- v0.89 released 2014-10-12, based on linux 3.14
- v0.90 released 2015-09-02, based on linux 3.18
- v0.91 released 2016-06-21, based on linux 4.1
- v0.92 released 2017-06-04, based on linux 4.4
So, I would say the project is active and focused on the long term.
There have been minor releases in-between these major releases, to
integrate bugfixes and update to latest stable kernel. For instance,
v0.91.2 was based on linux 4.1.35.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the arch-dev-public