From: Paolo Abeni <pabeni@redhat.com>
To: mptcp@lists.linux.dev
Subject: [PATCH v3 mptcp-next 0/4] mptcp: just another receive path refactor
Date: Sat, 30 Jul 2022 10:04:38 +0200 [thread overview]
Message-ID: <cover.1659165378.git.pabeni@redhat.com> (raw)
This is a refresh and rebase of an already shared work:
https://lore.kernel.org/mptcp/cover.1621963632.git.pabeni@redhat.com/
[1]
The motiviation for refreshing this is:
https://lore.kernel.org/mptcp/YtVhyGSsv1CWvPz4@xsang-OptiPlex-9020/
specifically it looks like that properly attaching mem_cg to the
msk socket would be (much?) easier if the RX path and the fwd memory
allocation would be under msk socket lock protection.
The first 2 patches are proably worthy even without the refactor,
but specifically the 2nd one is required to get a good mptcp-level
acking behavior when we move the rx under the socket lock.
The 3rd patch does the real work, and the 4th is a follow-up cleanup.
Back at [1], I measured relevant performance regressions in some
specific cases. I've done the same test here and I now see little to
noise changes. I guess that is mostly due to the better acking
strategy already introduce with commit 949dfdcf343c ("Merge branch
'mptcp-improve-mptcp-level-window-tracking'") and refined here.
v2 -> v3:
- dropped obsoleted comment in patch 2/4
- fixed compile warning in patch 3/4
v1 -> v2:
- fix build issue in patch 3/4 due to PEBKAC
- added missing commit messages(!!!) in patch 3/4 & 4/4
Paolo Abeni (4):
mptcp: move RCVPRUNE event later
mptcp: more accurate receive buffer updates
mptcp: move msk input path under full msk socket lock
mptcp: use common helper for rmem memory accounting
include/net/mptcp.h | 2 +
net/ipv4/tcp.c | 3 +
net/mptcp/options.c | 1 -
net/mptcp/protocol.c | 219 +++++++++++--------------------------------
net/mptcp/protocol.h | 12 ++-
5 files changed, 68 insertions(+), 169 deletions(-)
--
2.35.3
next reply other threads:[~2022-07-30 8:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-30 8:04 Paolo Abeni [this message]
2022-07-30 8:04 ` [PATCH v3 mptcp-next 1/4] mptcp: move RCVPRUNE event later Paolo Abeni
2022-07-30 8:04 ` [PATCH v3 mptcp-next 2/4] mptcp: more accurate receive buffer updates Paolo Abeni
2022-07-30 8:04 ` [PATCH v3 mptcp-next 3/4] mptcp: move msk input path under full msk socket lock Paolo Abeni
2022-07-30 8:04 ` [PATCH v3 mptcp-next 4/4] mptcp: use common helper for rmem memory accounting Paolo Abeni
2022-07-30 9:59 ` mptcp: use common helper for rmem memory accounting: Tests Results MPTCP CI
2022-08-01 10:50 ` [PATCH v3 mptcp-next 0/4] mptcp: just another receive path refactor Paolo Abeni
2022-08-02 22:11 ` Mat Martineau
2022-08-03 16:39 ` 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.1659165378.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.