[PATCH mptcp-next v3 0/2] mptcp: sched: add subflow avoid flag

Kalpan Jani posted 2 patches 4 days, 19 hours ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/multipath-tcp/mptcp_net-next tags/patchew/20260831094651.2682660-1-kalpan.jani@mpiricsoftware.com
include/uapi/linux/mptcp.h                    |  1 +
net/mptcp/bpf.c                               |  1 +
net/mptcp/diag.c                              |  2 +
net/mptcp/protocol.c                          |  4 +-
net/mptcp/protocol.h                          |  5 +-
net/mptcp/sched.c                             |  6 ++
.../testing/selftests/bpf/prog_tests/mptcp.c  | 16 +++++
.../selftests/bpf/progs/mptcp_bpf_avoid.c     | 70 +++++++++++++++++++
8 files changed, 102 insertions(+), 3 deletions(-)
create mode 100644 tools/testing/selftests/bpf/progs/mptcp_bpf_avoid.c
[PATCH mptcp-next v3 0/2] mptcp: sched: add subflow avoid flag
Posted by Kalpan Jani 4 days, 19 hours ago
The core benches a subflow via the "stale" bit after
net.mptcp.stale_loss_cnt retransmission intervals without progress.
That bit is core-owned and RTO-coupled -- cleared as soon as a packet
is acked on the subflow. A scheduler has no way to bench a subflow for
its own reasons (high latency, instability) independently of ack
traffic.

"scheduled" doesn't help either: the core clears it after every
send/retrans pass, so it can't hold a standing "leave this alone"
decision, and nothing outside the scheduler that set it can see it.

Changes since v2:

v2 was generated against a stale local snapshot that predated several
unrelated upstream commits touching the same bitfield region in
mptcp_subflow_context; applying v2 against the real export tree
produced a merge conflict in protocol.h. This series is a straight
rebase onto the current export tree -- no functional change from v2.
Only two things differ as a result of the rebase itself:

- avoid now leaves __unused:8 instead of __unused:7, since the real
  tree has 9 unused bits available at this point rather than 8.
- line offsets throughout protocol.c/protocol.h shifted to match
  current export.

Changes since v1:

- avoid now lives in the existing __unused bitfield padding instead
  of its own bool. No struct growth (Paolo).
- the selftest scheduler sets avoid once, on the first get_send()
  call, and only reads it back afterward -- proving persistence
  scheduled can't do, instead of just claiming it. A get_send_calls
  counter, asserted >1, makes sure multiple rounds actually ran
  (Paolo).
- mptcp_subflow_get_send() and mptcp_subflow_get_retrans() -- the
  default subflow picker, active with or without a custom scheduler
  -- now skip an avoided subflow next to the existing active-subflow
  check. avoid is also exposed via MPTCP diag (Paolo).
- set_avoid() marked __bpf_kfunc: it has no C callers, unlike
  set_scheduled(), and could be dropped under LTO before
  resolve_btfids finds it in BTF (review bot).
- added the missing extern __ksym for mptcp_subflow_active() in the
  selftest, matching mptcp_bpf_burst.c (review bot).
- moved the set_avoid extern out of mptcp_bpf.h into
  mptcp_bpf_avoid.c: checkpatch flags new externs in shared headers,
  and it has only the one caller.

Probing an avoided subflow to decide when to clear it (issue #348) is
left out on purpose -- that's scheduler policy, not core mechanism.

Patch 1 adds the flag, the kfunc, default-scheduler enforcement, and
diag support. Patch 2 reworks the selftest to prove persistence and
picks up the missing extern.

Ran the full suite through mptcp-upstream-virtme-docker (auto-normal
and auto-btf) -- selftests, packetdrill, and BPF tests pass, avoid
subtest included.

Link: https://github.com/multipath-tcp/mptcp_net-next/issues/349

Kalpan Jani (2):
  mptcp: sched: add subflow avoid flag and enforce it in core
  selftests: mptcp: bpf: exercise the subflow avoid flag across rounds

 include/uapi/linux/mptcp.h                    |  1 +
 net/mptcp/bpf.c                               |  1 +
 net/mptcp/diag.c                              |  2 +
 net/mptcp/protocol.c                          |  4 +-
 net/mptcp/protocol.h                          |  5 +-
 net/mptcp/sched.c                             |  6 ++
 .../testing/selftests/bpf/prog_tests/mptcp.c  | 16 +++++
 .../selftests/bpf/progs/mptcp_bpf_avoid.c     | 70 +++++++++++++++++++
 8 files changed, 102 insertions(+), 3 deletions(-)
 create mode 100644 tools/testing/selftests/bpf/progs/mptcp_bpf_avoid.c

base-commit: 21f4dd6665f74afe8fe39591e4abd5971828cf08
-- 
2.43.0
Re: [PATCH mptcp-next v3 0/2] mptcp: sched: add subflow avoid flag
Posted by MPTCP CI 4 days, 18 hours ago
Hi Kalpan,

Thank you for your modifications, that's great!

Our CI did some validations and here is its report:

- KVM Validation: normal (except selftest_mptcp_join): Success! ✅
- KVM Validation: normal (only selftest_mptcp_join): Success! ✅
- KVM Validation: debug (except selftest_mptcp_join): Notice: Call Traces at boot time, rebooted and continued ⚠️ 
- KVM Validation: debug (only selftest_mptcp_join): Notice: Call Traces at boot time, rebooted and continued ⚠️ 
- KVM Validation: btf-normal (only bpftest_all): Success! ✅
- KVM Validation: btf-debug (only bpftest_all): Notice: Call Traces at boot time, rebooted and continued - Notice: Call Traces at shutdown time, ignored and continued ⚠️ 
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/33381492140

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


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)