This series includes RX path improvement built around backlog processing

The main goals are improving the RX performances _and_ increase the
long term maintainability.

Patch 1 and 2 refactor the memory account logic in the RX path, so that
the msk don't need anymore to do fwd allocation, removing possible drop
sources.

Patch 3 and 4 cope with backlog processing. Patch 3 introduces the
helpers needed to manipulate the msk-level backlog, and the data struct
itself, without any actual functional change. Patch 4 finally use the
backlog for RX skb processing. Note that MPTCP can't use the sk_backlog,
as the mptcp release callback can also release and re-acquire the
msk-level spinlock and core backlog processing works under the
assumption that such event is not possible.

A relevant point is memory accounts for skbs in the backlog.

It's somewhat "original" due to MPTCP constraints. Such skbs use space
from the incoming subflow receive buffer, but are fwd memory accounted
on the msk, using memory borrowed by the subflow.

Instead the msk borrows memory from the subflow and reserve it for
the backlog - see patch 2 and 4 for the gory details.
---
v7 -> v8:
  - only minor changes: typos, added warn_on().
  - notably no BL loop limiting, as discussed on previous iteration

Paolo Abeni (4):
  mptcp: handle first subflow closing consistently
  mptcp: borrow forward memory from subflow
  mptcp: introduce mptcp-level backlog
  mptcp: leverage the backlog for RX packet processing

 net/mptcp/fastopen.c   |   4 +-
 net/mptcp/mib.c        |   1 -
 net/mptcp/mib.h        |   1 -
 net/mptcp/mptcp_diag.c |   3 +-
 net/mptcp/protocol.c   | 232 +++++++++++++++++++++++++++++------------
 net/mptcp/protocol.h   |  45 +++++++-
 6 files changed, 214 insertions(+), 72 deletions(-)

-- 
2.51.0

On Tue, 4 Nov 2025, Paolo Abeni wrote:

> This series includes RX path improvement built around backlog processing
>
> The main goals are improving the RX performances _and_ increase the
> long term maintainability.
>
> Patch 1 and 2 refactor the memory account logic in the RX path, so that
> the msk don't need anymore to do fwd allocation, removing possible drop
> sources.
>
> Patch 3 and 4 cope with backlog processing. Patch 3 introduces the
> helpers needed to manipulate the msk-level backlog, and the data struct
> itself, without any actual functional change. Patch 4 finally use the
> backlog for RX skb processing. Note that MPTCP can't use the sk_backlog,
> as the mptcp release callback can also release and re-acquire the
> msk-level spinlock and core backlog processing works under the
> assumption that such event is not possible.
>
> A relevant point is memory accounts for skbs in the backlog.
>
> It's somewhat "original" due to MPTCP constraints. Such skbs use space
> from the incoming subflow receive buffer, but are fwd memory accounted
> on the msk, using memory borrowed by the subflow.
>
> Instead the msk borrows memory from the subflow and reserve it for
> the backlog - see patch 2 and 4 for the gory details.
> ---
> v7 -> v8:
>  - only minor changes: typos, added warn_on().
>  - notably no BL loop limiting, as discussed on previous iteration
>

Thanks for the clarifications Paolo, v8 LGTM:

Reviewed-by: Mat Martineau <martineau@kernel.org>

> Paolo Abeni (4):
>  mptcp: handle first subflow closing consistently
>  mptcp: borrow forward memory from subflow
>  mptcp: introduce mptcp-level backlog
>  mptcp: leverage the backlog for RX packet processing
>
> net/mptcp/fastopen.c   |   4 +-
> net/mptcp/mib.c        |   1 -
> net/mptcp/mib.h        |   1 -
> net/mptcp/mptcp_diag.c |   3 +-
> net/mptcp/protocol.c   | 232 +++++++++++++++++++++++++++++------------
> net/mptcp/protocol.h   |  45 +++++++-
> 6 files changed, 214 insertions(+), 72 deletions(-)
>
> -- 
> 2.51.0
>
>
>

Hi Paolo,

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): Unstable: 1 failed test(s): packetdrill_sockopts 🔴
- KVM Validation: normal (only selftest_mptcp_join): Success! ✅
- KVM Validation: debug (except selftest_mptcp_join): Unstable: 1 failed test(s): selftest_mptcp_connect_mmap 🔴
- KVM Validation: debug (only selftest_mptcp_join): Success! ✅
- 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/19075373936

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


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)

Hi Paolo, Mat,

On 04/11/2025 16:59, Paolo Abeni wrote:
> This series includes RX path improvement built around backlog processing
> 
> The main goals are improving the RX performances _and_ increase the
> long term maintainability.
> 
> Patch 1 and 2 refactor the memory account logic in the RX path, so that
> the msk don't need anymore to do fwd allocation, removing possible drop
> sources.
> 
> Patch 3 and 4 cope with backlog processing. Patch 3 introduces the
> helpers needed to manipulate the msk-level backlog, and the data struct
> itself, without any actual functional change. Patch 4 finally use the
> backlog for RX skb processing. Note that MPTCP can't use the sk_backlog,
> as the mptcp release callback can also release and re-acquire the
> msk-level spinlock and core backlog processing works under the
> assumption that such event is not possible.
> 
> A relevant point is memory accounts for skbs in the backlog.
> 
> It's somewhat "original" due to MPTCP constraints. Such skbs use space
> from the incoming subflow receive buffer, but are fwd memory accounted
> on the msk, using memory borrowed by the subflow.
> 
> Instead the msk borrows memory from the subflow and reserve it for
> the backlog - see patch 2 and 4 for the gory details.
> ---
> v7 -> v8:
>   - only minor changes: typos, added warn_on().
>   - notably no BL loop limiting, as discussed on previous iteration
> 
> Paolo Abeni (4):
>   mptcp: handle first subflow closing consistently
>   mptcp: borrow forward memory from subflow
>   mptcp: introduce mptcp-level backlog
>   mptcp: leverage the backlog for RX packet processing

Thank you for the patches and the reviews!

Now in our tree:

New patches for t/upstream:
- acccba36fa8b: mptcp: handle first subflow closing consistently
- 858caff062de: mptcp: borrow forward memory from subflow
- 4a9aeb444ecf: mptcp: introduce mptcp-level backlog
- d09fc4521e3a: mptcp: leverage the backlog for RX packet processing
- Results: 24301f878352..c0bd85030030 (export)

Tests are now in progress:

- export:
https://github.com/multipath-tcp/mptcp_net-next/commit/288a453d00d9ed545fa108e32485f407a07a6d32/checks

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