MPTCP Linux Development
 help / color / mirror / Atom feed
From: Paolo Abeni <pabeni@redhat.com>
To: mptcp@lists.linux.dev
Cc: Mat Martineau <martineau@kernel.org>, geliang@kernel.org
Subject: [PATCH RESENT v7 mptcp-next 0/4] mptcp: introduce backlog processing
Date: Mon, 27 Oct 2025 15:57:58 +0100	[thread overview]
Message-ID: <cover.1761576117.git.pabeni@redhat.com> (raw)

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.

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   | 231 +++++++++++++++++++++++++++++------------
 net/mptcp/protocol.h   |  40 ++++++-
 6 files changed, 208 insertions(+), 72 deletions(-)

-- 
2.51.0


             reply	other threads:[~2025-10-27 14:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-27 14:57 Paolo Abeni [this message]
2025-10-27 14:57 ` [PATCH RESENT v7 mptcp-next 1/4] mptcp: handle first subflow closing consistently Paolo Abeni
2025-10-27 14:58 ` [PATCH RESENT v7 mptcp-next 2/4] mptcp: borrow forward memory from subflow Paolo Abeni
2025-10-31 22:44   ` Mat Martineau
2025-11-03 16:26     ` Paolo Abeni
2025-10-27 14:58 ` [PATCH RESENT v7 mptcp-next 3/4] mptcp: introduce mptcp-level backlog Paolo Abeni
2025-10-27 14:58 ` [PATCH RESENT v7 mptcp-next 4/4] mptcp: leverage the backlog for RX packet processing Paolo Abeni
2025-11-01  0:04   ` Mat Martineau
2025-11-03 16:23     ` Paolo Abeni
2025-11-04 22:32       ` Mat Martineau
2025-10-27 16:13 ` [PATCH RESENT v7 mptcp-next 0/4] mptcp: introduce backlog processing MPTCP CI

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=cover.1761576117.git.pabeni@redhat.com \
    --to=pabeni@redhat.com \
    --cc=geliang@kernel.org \
    --cc=martineau@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox