From: gang.yan@linux.dev
To: mptcp@lists.linux.dev
Subject: Re: [PATCH mptcp-next v5 0/3] only remove entry from local_addr_list when sending a REMOVE_ADDR
Date: Fri, 26 Jun 2026 10:24:00 +0000 [thread overview]
Message-ID: <0bdfd823d64a18b9c9230d176082289418d25a4a@linux.dev> (raw)
In-Reply-To: <74f86b7879f96bd71d989e4323750c4bf77627c5@linux.dev>
>
> From: Geliang Tang <tanggeliang@kylinos.cn>
>
> v5:
> - rebased.
> - add Matt's reviewed tags.
> - add a RM_ADDR from the server to the client as Sashiko suggested.
> - mptcpd tests (make check) are still OK after this modification.
>
Hi Matt,
Sorry for the off-list email before, I forget to cc the mptcp@lists.linux.dev
First, no offense intended — this is in no way a comment on this patch.
The patch itself looks good to me. I'm replying here only because the
thought came up while reading it.
While looking at mptcpd recently, I noticed that 'make check' doesn't
seem to exercise the userspace PM logic in a meaningful way. The
userspace PM cases in test-commands issue the per-connection (mptcpd_pm_*)
calls with a fake token that doesn't correspond to any real MPTCP connection,
so they only really verify that the command dispatches and the genl request
is sent without crashing.
This made me wonder whether it would be worthwhile to add functional tests
for mptcpd within the selftest framework — for example, via a dedicated script
(something like selftest_mptcpd.sh) that actually starts mptcpd with specific
plugins (e.g., sspi) in a namespace/veth environment, and then asserts the
expected path-manager behavior end-to-end.
In other words, I'm asking: does the community think mptcpd's userspace PM
functionality deserves similar test coverage within selftest?
Thanks
Gang
>
> v4:
> - rebased.
> - Link: https://patchwork.kernel.org/project/mptcp/cover/cover.1776466833.git.tanggeliang@kylinos.cn/
>
> v3:
> - update userspace selftests.
> - Link: https://patchwork.kernel.org/project/mptcp/cover/cover.1744787273.git.tanggeliang@kylinos.cn/
>
> v2:
> - squash patch 1 into patch 2 as Mat suggested.
>
> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/403
>
> Geliang Tang (3):
> mptcp: pm: userspace: drop delete_local_addr helper
> selftests: mptcp: join: update userspace dump_addr outputs
> selftests: mptcp: userspace: send RM_ADDR between server and client
>
> net/mptcp/pm_userspace.c | 35 ++-----------------
> .../testing/selftests/net/mptcp/mptcp_join.sh | 6 ++--
> .../selftests/net/mptcp/userspace_pm.sh | 16 +++++++++
> 3 files changed, 21 insertions(+), 36 deletions(-)
>
> --
> 2.53.0
>
prev parent reply other threads:[~2026-06-26 10:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-26 7:16 [PATCH mptcp-next v5 0/3] only remove entry from local_addr_list when sending a REMOVE_ADDR Geliang Tang
2026-06-26 7:16 ` [PATCH mptcp-next v5 1/3] mptcp: pm: userspace: drop delete_local_addr helper Geliang Tang
2026-06-26 7:16 ` [PATCH mptcp-next v5 2/3] selftests: mptcp: join: update userspace dump_addr outputs Geliang Tang
2026-06-26 7:16 ` [PATCH mptcp-next v5 3/3] selftests: mptcp: userspace: send RM_ADDR between server and client Geliang Tang
2026-06-26 8:19 ` [PATCH mptcp-next v5 0/3] only remove entry from local_addr_list when sending a REMOVE_ADDR MPTCP CI
[not found] ` <74f86b7879f96bd71d989e4323750c4bf77627c5@linux.dev>
2026-06-26 10:24 ` gang.yan [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0bdfd823d64a18b9c9230d176082289418d25a4a@linux.dev \
--to=gang.yan@linux.dev \
--cc=mptcp@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.