Re: [PATCH mptcp-next 0/2] mptcp: sched: let schedulers mark a subflow to avoid

On 7/15/26 12:11 PM, Kalpan Jani wrote:
> The core benches a subflow via the "stale" bit after
> net.mptcp.stale_loss_cnt retransmission intervals without progress. That
> bit is owned by the core and tightly coupled to the RTO: it is cleared as
> soon as a packet is acked on the subflow, in mptcp_subflow_active(). A
> packet scheduler therefore cannot repurpose it to bench a subflow for its
> own reasons (too high latency, too unstable) and keep it benched: the core
> would clear it on the next ack, unrelated to the scheduler's intent.
> 
> Add a separate, scheduler-owned "avoid" flag on the subflow context, set
> and cleared only through mptcp_subflow_set_avoid(), exposed to BPF
> struct_ops schedulers as a kfunc (same registration and filter as
> mptcp_subflow_set_scheduled(), so only schedulers can call it). The flag is
> scheduler-local state: the scheduler sets it to remember a subflow should
> be skipped and consults it when picking a subflow to send on. It lives in
> the struct_group(reset) block, so it is cleared on subflow reset and a
> re-established path is re-evaluated. The core send and retransmit paths are
> left unchanged.
> 
> This is the "manage a new bit" option from issue #349, kept independent of
> the RTO-driven stale bit as that issue requests. Regular probing of an
> avoided subflow (#348) and any core-side consumption of the flag are left
> for follow-up.
> 
> Patch 1 adds the flag, the setter and the kfunc. Patch 2 adds a BPF
> struct_ops scheduler selftest that marks all but the first subflow avoided,
> reads the flag back, and schedules only a non-avoided subflow; the existing
> harness confirms the avoided path carries no data, exercising the kfunc
> round-trip from eBPF.
> 
> Tested with the mptcp-upstream-virtme-docker CI (auto-normal and auto-btf):
> all selftests, packetdrill and BPF tests pass, including the new avoid
> subtest.
> 
> Link: https://github.com/multipath-tcp/mptcp_net-next/issues/349

Please note that the above issue was filed before the introduction of
the 'scheduled' flag.

I don't see the `avoid` bool adding more capabilities on top of the
other field, and without any usage from the core I think this change
misses a relevant point from the linked issue.

Finally the proposed patch creates a 4 bytes hole in the subflow struct,
possibly a better location is available.

More importantly you need to provide a meaningful working scenario
demonstrating a relevant use-case not covered by the `scheduled` bit.

/P