From: Mat Martineau <martineau@kernel.org>
To: Paolo Abeni <pabeni@redhat.com>
Cc: mptcp@lists.linux.dev
Subject: Re: [PATCH mptcp-next v2 6/7] mptcp: cleanup mem accounting.
Date: Fri, 6 Dec 2024 17:45:40 -0800 (PST) [thread overview]
Message-ID: <7eb7bd25-b6b2-9561-bec3-7b51020a21fb@kernel.org> (raw)
In-Reply-To: <152364cf85476115c84f435d76a8f04da9e2d089.1733486870.git.pabeni@redhat.com>
On Fri, 6 Dec 2024, Paolo Abeni wrote:
> After the previous patch, updating sk_forward_memory is cheap and
> we can drop a lot of complexity from the MPTCP memory acconting,
> removing the custom fwd mem allocations for rmem.
>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
> v1 -> v2:
> - keep 'snd_una' and recovery-related fields under the msk
> data lock
> - dropped unneeded code in __mptcp_move_skbs()
> ---
> net/mptcp/fastopen.c | 2 +-
> net/mptcp/protocol.c | 115 +++----------------------------------------
> net/mptcp/protocol.h | 4 +-
> 3 files changed, 10 insertions(+), 111 deletions(-)
>
> diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
> index ad940cc1f26f..a0d46b69746d 100644
> --- a/net/mptcp/protocol.h
> +++ b/net/mptcp/protocol.h
> @@ -278,7 +278,6 @@ struct mptcp_sock {
> u64 rcv_data_fin_seq;
> u64 bytes_retrans;
> u64 bytes_consumed;
> - int rmem_fwd_alloc;
> int snd_burst;
> int old_wspace;
> u64 recovery_snd_nxt; /* in recovery mode accept up to this seq;
> @@ -293,7 +292,6 @@ struct mptcp_sock {
> u32 last_ack_recv;
> unsigned long timer_ival;
> u32 token;
> - int rmem_released;
> unsigned long flags;
> unsigned long cb_flags;
> bool recovery; /* closing subflow write queue reinjected */
> @@ -384,7 +382,7 @@ static inline void msk_owned_by_me(const struct mptcp_sock *msk)
> */
> static inline int __mptcp_rmem(const struct sock *sk)
> {
> - return atomic_read(&sk->sk_rmem_alloc) - READ_ONCE(mptcp_sk(sk)->rmem_released);
> + return atomic_read(&sk->sk_rmem_alloc);
> }
Hi Paolo -
Minor change: this helper is now exactly the same as sk_rmem_alloc_get(),
so use that existing helper instead.
Thats actually the only suggestion I have for v2! Good to delete code and
improve performance. I also think the release_cb approach on rx is a good
idea because it could be further leveraged to help with redundant
schedulers (our main problem there was trying to trigger sends on other
subflows when we couldn't acquire the msk lock).
- Mat
>
> static inline int mptcp_win_from_space(const struct sock *sk, int space)
> --
> 2.45.2
>
>
>
next prev parent reply other threads:[~2024-12-07 1:45 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-06 12:09 [PATCH mptcp-next v2 0/7] mptcp: rx path refactor Paolo Abeni
2024-12-06 12:10 ` [PATCH mptcp-next v2 1/7] mptcp: prevent excessive coalescing on receive Paolo Abeni
2024-12-10 12:03 ` Matthieu Baerts
2024-12-21 10:00 ` Matthieu Baerts
2024-12-27 9:40 ` Paolo Abeni
2024-12-30 18:24 ` Matthieu Baerts
2024-12-06 12:10 ` [PATCH mptcp-next v2 2/7] tcp: fix recvbuffer adjust on sleeping rcvmsg Paolo Abeni
2024-12-06 12:10 ` [PATCH mptcp-next v2 3/7] mptcp: don't always assume copied data in mptcp_cleanup_rbuf() Paolo Abeni
2024-12-06 12:10 ` [PATCH mptcp-next v2 4/7] mptcp: consolidate subflow cleanup Paolo Abeni
2024-12-06 12:11 ` [PATCH mptcp-next v2 5/7] mptcp: move the whole rx path under msk socket lock protection Paolo Abeni
2024-12-06 12:11 ` [PATCH mptcp-next v2 6/7] mptcp: cleanup mem accounting Paolo Abeni
2024-12-07 1:45 ` Mat Martineau [this message]
2024-12-10 9:00 ` Paolo Abeni
2024-12-06 12:11 ` [PATCH mptcp-next v2 7/7] net: dismiss sk_forward_alloc_get() Paolo Abeni
2024-12-06 13:17 ` [PATCH mptcp-next v2 0/7] mptcp: rx path refactor MPTCP CI
2024-12-06 16:41 ` Paolo Abeni
2024-12-21 2:12 ` Mat Martineau
2024-12-21 11: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=7eb7bd25-b6b2-9561-bec3-7b51020a21fb@kernel.org \
--to=martineau@kernel.org \
--cc=mptcp@lists.linux.dev \
--cc=pabeni@redhat.com \
/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