MPTCP Linux Development
 help / color / mirror / Atom feed
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
>
>
>

  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