From: Paolo Abeni <pabeni@redhat.com>
To: mptcp@lists.linux.dev
Subject: [PATCH v4 mptcp-next 0/8] mptcp: introduce backlog processing
Date: Fri, 3 Oct 2025 16:01:38 +0200 [thread overview]
Message-ID: <cover.1759499837.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 1-3 prepare the stack for backlog processing, removing
assumptions that will not hold true anymore after backlog introduction.
Patch 4 fixes a long standing issue which is quite hard to reproduce
with the current implementation but will become very apparent with
backlog usage.
Patches 5 and 6 are more cleanups that will make the backlog patch a
little less huge.
Patch 7 is a somewhat unrelated cleanup, included here before I forgot
about it.
The real work is done by patch 8. There are significant changes vs the
previous iteration, as it turned out we 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.
Other relevant points are:
- skbs in the backlog are _not_ accounted. TCP does the same, and we
can't update the fwd mem while enqueuing to the backlog as the caller
does not own the msk-level socket lock nor can acquire it.
- skbs in the backlog still use the incoming ssk rmem. This allows
backpressure and implicitly prevent excessive memory usage for the
backlog itself
- [this is possibly the most critical point]: when the msk rx buf is
full, we don't add more packets there even when the caller owns the
msk socket lock. Instead packets are added to the backlog. Note that
the amount of memory used there is still limited by the above. Also
note that this implicitly means that such packets could stage in the
backlog until the receiver flushes the rx buffer - an unbound amount
of time. That is not supposed to happen for the backlog, ence the
criticality here.
This survived a few hours of selftest iterations in a loop: should
address all functional issues observed in previous iterations (and
possibly includes different ones ;)
Paolo Abeni (8):
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: leverage the backlog for RX packet processing
net/mptcp/pm.c | 4 +-
net/mptcp/pm_kernel.c | 2 +
net/mptcp/protocol.c | 306 +++++++++++++++++++++++++++---------------
net/mptcp/protocol.h | 7 +-
net/mptcp/subflow.c | 12 +-
5 files changed, 215 insertions(+), 116 deletions(-)
--
2.51.0
next reply other threads:[~2025-10-03 14:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-03 14:01 Paolo Abeni [this message]
2025-10-03 14:01 ` [PATCH v4 mptcp-next 1/8] mptcp: borrow forward memory from subflow Paolo Abeni
2025-10-03 15:41 ` Matthieu Baerts
2025-10-03 14:01 ` [PATCH v4 mptcp-next 2/8] mptcp: cleanup fallback data fin reception Paolo Abeni
2025-10-03 14:01 ` [PATCH v4 mptcp-next 3/8] mptcp: cleanup fallback dummy mapping generation Paolo Abeni
2025-10-03 14:01 ` [PATCH v4 mptcp-next 4/8] mptcp: fix MSG_PEEK stream corruption Paolo Abeni
2025-10-03 14:01 ` [PATCH v4 mptcp-next 5/8] mptcp: ensure the kernel PM does not take action too late Paolo Abeni
2025-10-03 14:01 ` [PATCH v4 mptcp-next 6/8] mptcp: do not miss early first subflow close event notification Paolo Abeni
2025-10-03 14:01 ` [PATCH v4 mptcp-next 7/8] mptcp: make mptcp_destroy_common() static Paolo Abeni
2025-10-03 14:01 ` [PATCH v4 mptcp-next 8/8] mptcp: leverage the backlog for RX packet processing Paolo Abeni
2025-10-06 5:09 ` Geliang Tang
2025-10-06 7:51 ` Paolo Abeni
2025-10-03 16:10 ` [PATCH v4 mptcp-next 0/8] mptcp: introduce backlog processing MPTCP CI
2025-10-04 1:26 ` Geliang Tang
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.1759499837.git.pabeni@redhat.com \
--to=pabeni@redhat.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.