From: Paolo Abeni <pabeni@redhat.com>
To: mptcp@lists.linux.dev
Cc: Mat Martineau <martineau@kernel.org>, Geliang Tang <geliang@kernel.org>
Subject: [PATCH v6 mptcp-next 00/11] mptcp: introduce backlog processing
Date: Wed, 22 Oct 2025 16:31:43 +0200 [thread overview]
Message-ID: <cover.1761142784.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.
Patches 2-4 prepare the stack for backlog processing, removing
assumptions that will not hold true anymore after backlog introduction.
Patches 1 and 5 fixes long standing issues which are quite hard to
reproduce with the current implementation but the 2nd one will become
very apparent with backlog usage.
Patches 6, 7 and 9 are more cleanups that will make the backlog patch a
little less huge.
Patch 8 is a somewhat unrelated cleanup, included here before I forgot
about it.
The real work is done by patch 10 and 11. Patch 10 introduces the helpers
needed to manipulate the msk-level backlog, and the data struct itself,
without any actual functional change. Patch 11 finally use the backlog
for RX skb processing. Note that MPTCP can't uset 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, do not use explicitly any
forward allocated memory, as we can't update the msk fwd mem while
enqueuing, nor we want to acquire again the ssk socket lock while
processing the skbs.
Instead the msk borrows memory from the subflow and reserve it for
the backlog - see patch 3 and 11 for the gory details.
Note that even if the skbs can sit in the backlog for an unbounded time,
---
v5 -> v6:
- added patch 1/11
- reworked widely patch 10 && 11 to avoid double accounts for backlog
skb and to address the fwd allocated memory criticality mentioned
in previous iterations.
Paolo Abeni (11):
mptcp: drop bogus optimization in __mptcp_check_push()
mptcp: borrow forward memory from subflow
mptcp: cleanup fallback data fin reception
mptcp: cleanup fallback dummy mapping generation
mptcp: fix MSG_PEEK stream corruption
mptcp: ensure the kernel PM does not take action too late
mptcp: do not miss early first subflow close event notification.
mptcp: make mptcp_destroy_common() static
mptcp: drop the __mptcp_data_ready() helper
mptcp: introduce mptcp-level backlog
mptcp: leverage the backlog for RX packet processing
net/mptcp/mptcp_diag.c | 3 +-
net/mptcp/pm.c | 4 +-
net/mptcp/pm_kernel.c | 2 +
net/mptcp/protocol.c | 363 ++++++++++++++++++++++++++++-------------
net/mptcp/protocol.h | 10 +-
net/mptcp/subflow.c | 12 +-
6 files changed, 272 insertions(+), 122 deletions(-)
--
2.51.0
next reply other threads:[~2025-10-22 14:32 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-22 14:31 Paolo Abeni [this message]
2025-10-22 14:31 ` [PATCH v6 mptcp-next 01/11] mptcp: drop bogus optimization in __mptcp_check_push() Paolo Abeni
2025-10-22 14:31 ` [PATCH v6 mptcp-next 02/11] mptcp: borrow forward memory from subflow Paolo Abeni
2025-10-23 6:38 ` Geliang Tang
2025-10-22 14:31 ` [PATCH v6 mptcp-next 03/11] mptcp: cleanup fallback data fin reception Paolo Abeni
2025-10-22 14:31 ` [PATCH v6 mptcp-next 04/11] mptcp: cleanup fallback dummy mapping generation Paolo Abeni
2025-10-22 14:31 ` [PATCH v6 mptcp-next 05/11] mptcp: fix MSG_PEEK stream corruption Paolo Abeni
2025-10-23 16:56 ` Mat Martineau
2025-10-24 7:34 ` Paolo Abeni
2025-10-22 14:31 ` [PATCH v6 mptcp-next 06/11] mptcp: ensure the kernel PM does not take action too late Paolo Abeni
2025-10-22 14:31 ` [PATCH v6 mptcp-next 07/11] mptcp: do not miss early first subflow close event notification Paolo Abeni
2025-10-22 14:31 ` [PATCH v6 mptcp-next 08/11] mptcp: make mptcp_destroy_common() static Paolo Abeni
2025-10-22 14:31 ` [PATCH v6 mptcp-next 09/11] mptcp: drop the __mptcp_data_ready() helper Paolo Abeni
2025-10-23 6:38 ` Geliang Tang
2025-10-22 14:31 ` [PATCH v6 mptcp-next 10/11] mptcp: introduce mptcp-level backlog Paolo Abeni
2025-10-22 14:31 ` [PATCH v6 mptcp-next 11/11] mptcp: leverage the backlog for RX packet processing Paolo Abeni
2025-10-23 15:11 ` Paolo Abeni
2025-10-23 15:52 ` Matthieu Baerts
2025-10-23 17:02 ` Mat Martineau
2025-10-23 17:43 ` Matthieu Baerts
2025-10-22 15:50 ` [PATCH v6 mptcp-next 00/11] mptcp: introduce backlog processing MPTCP CI
2025-10-23 6:37 ` Geliang Tang
2025-10-27 12:17 ` Matthieu Baerts
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.1761142784.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