net/mptcp/pm.c | 7 +++-- net/mptcp/pm_kernel.c | 37 +++++++++++++++++++++++++ net/mptcp/protocol.h | 7 +++++ tools/testing/selftests/net/mptcp/mptcp_join.sh | 11 ++++++++ 4 files changed, 60 insertions(+), 2 deletions(-)
When servers set the C-flag in their MP_CAPABLE to tell clients not to
create subflows to the initial address and port, clients will likely not
use their other endpoints. That's because the in-kernel path-manager
uses the 'subflow' endpoints to create subflows only to the initial
address and port.
The first patch fixes that, and the second one validates it.
More details: https://github.com/multipath-tcp/mptcp_net-next/issues/536
Please see the comment in the first patch, and don't hesitate to reply :)
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
Changes in v2:
- patch 1: move cond to new helper (Geliang) + rename var, squash comm.
- patch 2: move accidental .c modif to the parent commit (Geliang)
- Link to v1: https://lore.kernel.org/r/20250915-pm-c-flag-client-default-v1-0-6bb241e4d991@kernel.org
---
Matthieu Baerts (NGI0) (2):
mptcp: pm: in-kernel: usable client side with C-flag
selftests: mptcp: join: validate C-flag + def limit
net/mptcp/pm.c | 7 +++--
net/mptcp/pm_kernel.c | 37 +++++++++++++++++++++++++
net/mptcp/protocol.h | 7 +++++
tools/testing/selftests/net/mptcp/mptcp_join.sh | 11 ++++++++
4 files changed, 60 insertions(+), 2 deletions(-)
---
base-commit: 01d3ba86f43b6fe8e91cfd00ba178d6997095a04
change-id: 20250912-pm-c-flag-client-default-f676d8acfdc7
Best regards,
--
Matthieu Baerts (NGI0) <matttbe@kernel.org>
Hi Matt, On Tue, 2025-09-16 at 13:01 +0200, Matthieu Baerts (NGI0) wrote: > When servers set the C-flag in their MP_CAPABLE to tell clients not > to > create subflows to the initial address and port, clients will likely > not > use their other endpoints. That's because the in-kernel path-manager > uses the 'subflow' endpoints to create subflows only to the initial > address and port. > > The first patch fixes that, and the second one validates it. > > More details: > https://github.com/multipath-tcp/mptcp_net-next/issues/536 > > Please see the comment in the first patch, and don't hesitate to > reply :) > > Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Thanks for this v2. LGTM! Reviewed-by: Geliang Tang <geliang@kernel.org> -Geliang > --- > Changes in v2: > - patch 1: move cond to new helper (Geliang) + rename var, squash > comm. > - patch 2: move accidental .c modif to the parent commit (Geliang) > - Link to v1: > https://lore.kernel.org/r/20250915-pm-c-flag-client-default-v1-0-6bb241e4d991@kernel.org > > --- > Matthieu Baerts (NGI0) (2): > mptcp: pm: in-kernel: usable client side with C-flag > selftests: mptcp: join: validate C-flag + def limit > > net/mptcp/pm.c | 7 +++-- > net/mptcp/pm_kernel.c | 37 > +++++++++++++++++++++++++ > net/mptcp/protocol.h | 7 +++++ > tools/testing/selftests/net/mptcp/mptcp_join.sh | 11 ++++++++ > 4 files changed, 60 insertions(+), 2 deletions(-) > --- > base-commit: 01d3ba86f43b6fe8e91cfd00ba178d6997095a04 > change-id: 20250912-pm-c-flag-client-default-f676d8acfdc7 > > Best regards,
Hi Geliang, On 19/09/2025 12:15, Geliang Tang wrote: > Hi Matt, > > On Tue, 2025-09-16 at 13:01 +0200, Matthieu Baerts (NGI0) wrote: >> When servers set the C-flag in their MP_CAPABLE to tell clients not >> to >> create subflows to the initial address and port, clients will likely >> not >> use their other endpoints. That's because the in-kernel path-manager >> uses the 'subflow' endpoints to create subflows only to the initial >> address and port. >> >> The first patch fixes that, and the second one validates it. >> >> More details: >> https://github.com/multipath-tcp/mptcp_net-next/issues/536 >> >> Please see the comment in the first patch, and don't hesitate to >> reply :) >> >> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> > > Thanks for this v2. > > LGTM! > > Reviewed-by: Geliang Tang <geliang@kernel.org> Thank you for the review! Now in our tree. I decided to add them in the section for net-next: we are close to the merge window, and linked to the comment from patch 1, it is certainly safer to delay the backport to stable a bit. New patches for t/upstream: - 0b324b1e22a0: mptcp: pm: in-kernel: usable client side with C-flag - b366bcbbad02: "squashed" patch 1/10 in "mptcp: pm: in-kernel: usable client side with C-flag" - c3ca688abf65: selftests: mptcp: join: validate C-flag + def limit - Results: fe9c68017366..8a1a30937c29 (export) Cheers, Matt -- Sponsored by the NGI0 Core fund.
On 19/09/2025 12:47, Matthieu Baerts wrote: > Hi Geliang, > > On 19/09/2025 12:15, Geliang Tang wrote: >> Hi Matt, >> >> On Tue, 2025-09-16 at 13:01 +0200, Matthieu Baerts (NGI0) wrote: >>> When servers set the C-flag in their MP_CAPABLE to tell clients not >>> to >>> create subflows to the initial address and port, clients will likely >>> not >>> use their other endpoints. That's because the in-kernel path-manager >>> uses the 'subflow' endpoints to create subflows only to the initial >>> address and port. >>> >>> The first patch fixes that, and the second one validates it. >>> >>> More details: >>> https://github.com/multipath-tcp/mptcp_net-next/issues/536 >>> >>> Please see the comment in the first patch, and don't hesitate to >>> reply :) >>> >>> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> >> >> Thanks for this v2. >> >> LGTM! >> >> Reviewed-by: Geliang Tang <geliang@kernel.org> > > Thank you for the review! > > Now in our tree. I decided to add them in the section for net-next: we > are close to the merge window, and linked to the comment from patch 1, > it is certainly safer to delay the backport to stable a bit. > > New patches for t/upstream: > - 0b324b1e22a0: mptcp: pm: in-kernel: usable client side with C-flag > - b366bcbbad02: "squashed" patch 1/10 in "mptcp: pm: in-kernel: usable > client side with C-flag" > - c3ca688abf65: selftests: mptcp: join: validate C-flag + def limit > - Results: fe9c68017366..8a1a30937c29 (export) I forgot the last bit: - Results: fe9c68017366..169aef388767 (export) Tests are now in progress: - export: https://github.com/multipath-tcp/mptcp_net-next/commit/df63a09d28d2808cbe27f96a1937ad904035d2d6/checks Cheers, Matt -- Sponsored by the NGI0 Core fund.
Hi Matthieu,
Thank you for your modifications, that's great!
Our CI did some validations and here is its report:
- KVM Validation: normal: Success! ✅
- KVM Validation: debug: Unstable: 1 failed test(s): packetdrill_mp_capable 🔴
- KVM Validation: btf-normal (only bpftest_all): Success! ✅
- KVM Validation: btf-debug (only bpftest_all): Success! ✅
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/17764130273
Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/cbd9718b7233
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=1002880
If there are some issues, you can reproduce them using the same environment as
the one used by the CI thanks to a docker image, e.g.:
$ cd [kernel source code]
$ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
--pull always mptcp/mptcp-upstream-virtme-docker:latest \
auto-normal
For more details:
https://github.com/multipath-tcp/mptcp-upstream-virtme-docker
Please note that despite all the efforts that have been already done to have a
stable tests suite when executed on a public CI like here, it is possible some
reported issues are not due to your modifications. Still, do not hesitate to
help us improve that ;-)
Cheers,
MPTCP GH Action bot
Bot operated by Matthieu Baerts (NGI0 Core)
© 2016 - 2025 Red Hat, Inc.