[PATCH mptcp-next v3 00/15] refactor PM interfaces

Geliang Tang posted 15 patches 1 month, 2 weeks ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/multipath-tcp/mptcp_net-next tags/patchew/cover.1728538975.git.tanggeliang@kylinos.cn
net/mptcp/pm.c           |  17 ++-
net/mptcp/pm_netlink.c   | 245 ++++++++++++++++++++-------------------
net/mptcp/pm_userspace.c | 168 ++++++++-------------------
net/mptcp/protocol.h     |  50 ++++----
net/mptcp/subflow.c      |   2 +-
5 files changed, 220 insertions(+), 262 deletions(-)
[PATCH mptcp-next v3 00/15] refactor PM interfaces
Posted by Geliang Tang 1 month, 2 weeks ago
From: Geliang Tang <tanggeliang@kylinos.cn>

v3:
 - two more patches, 14-15, drop struct mptcp_pm_local and struct
mptcp_pm_add_entry.

v2:
 - split patch 5 into two.
 - new patches 9-13.

In order to implement BPF path manager, this set refactors get_addr
and dump_addr interfaces of PM.

Depends on:
 - cleanups for PM interfaces, v3

Based-on: <cover.1728298100.git.tanggeliang@kylinos.cn>

Geliang Tang (15):
  mptcp: add id parameter for get_addr
  mptcp: add addr parameter for get_addr
  mptcp: reuse sending nlmsg code in get_addr
  mptcp: change info of get_addr as const
  mptcp: refactor dump_addr with id bitmap
  mptcp: refactor dump_addr with get_addr
  mptcp: reuse sending nlmsg code in dump_addr
  mptcp: add loc and rem for set_flags
  mptcp: update address type of get_local_id
  mptcp: change is_backup interfaces as get_flags
  mptcp: hold pm lock when deleting entry
  mptcp: rename mptcp_pm_remove_addrs
  mptcp: drop free_list for deleting entries
  mptcp: drop struct mptcp_pm_local
  mptcp: drop struct mptcp_pm_add_entry

 net/mptcp/pm.c           |  17 ++-
 net/mptcp/pm_netlink.c   | 245 ++++++++++++++++++++-------------------
 net/mptcp/pm_userspace.c | 168 ++++++++-------------------
 net/mptcp/protocol.h     |  50 ++++----
 net/mptcp/subflow.c      |   2 +-
 5 files changed, 220 insertions(+), 262 deletions(-)

-- 
2.43.0
Re: [PATCH mptcp-next v3 00/15] refactor PM interfaces
Posted by MPTCP CI 1 month, 2 weeks ago
Hi Geliang,

Thank you for your modifications, that's great!

Our CI did some validations and here is its report:

- KVM Validation: normal: Unstable: 1 failed test(s): packetdrill_dss 🔴
- KVM Validation: debug: Unstable: 1 failed test(s): packetdrill_dss 🔴
- KVM Validation: btf (only bpftest_all): Success! ✅
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/11268311983

Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/8a88c16c3a19
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=897455


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)
Re: [PATCH mptcp-next v3 00/15] refactor PM interfaces
Posted by Matthieu Baerts 1 month, 1 week ago
Hi Geliang,

On 10/10/2024 08:52, MPTCP CI wrote:
> Hi Geliang,
> 
> Thank you for your modifications, that's great!
> 
> Our CI did some validations and here is its report:
> 
> - KVM Validation: normal: Unstable: 1 failed test(s): packetdrill_dss 🔴
> - KVM Validation: debug: Unstable: 1 failed test(s): packetdrill_dss 🔴

That's interesting: the CI had this error, because the code doesn't have
"mptcp: fallback when MPTCP opts are dropped after 1st data" commit.

  https://github.com/multipath-tcp/mptcp_net-next/commits/8a88c16c3a19

That's appently because when using the "Based-on", Patchew will use the
tag it created, then apply the new patches. It will then not use the
last version of the "export" branch, then apply the dependences, then
the new ones.

In other words, we can ignore the failed tests here.

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.