All of lore.kernel.org
 help / color / mirror / Atom feed
From: gang.yan@linux.dev
To: mptcp@lists.linux.dev
Subject: Re: [PATCH mptcp-net] mptcp: update window_clamp on subflows when SO_RCVBUF is set
Date: Thu, 16 Apr 2026 12:33:44 +0000	[thread overview]
Message-ID: <b5e178f01d0f9523d48d163a56488756ce20450f@linux.dev> (raw)
In-Reply-To: <20260416122945.324166-1-gang.yan@linux.dev>

April 16, 2026 at 8:29 PM, "Gang Yan" <gang.yan@linux.dev mailto:gang.yan@linux.dev?to=%22Gang%20Yan%22%20%3Cgang.yan%40linux.dev%3E > wrote:


> 
> From: Gang Yan <yangang@kylinos.cn>
> 
> Add __mptcp_subflow_set_rcvbuf() helper that calls the subflow's
> ops->set_rcvbuf to update window_clamp, in addition to writing
> sk_rcvbuf. Use it in both mptcp_sol_socket_sync_intval() (setsockopt
> path) and sync_socket_options() (new subflow creation path).
> 
Sorry for the confusion in my commit message.

I need to clarify that we cannot call ops->set_rcvbuf() on the MPTCP
subflows as mentioned in the commit message. I will fix this mistake
and update the commit message properly in the next version.

Thank you for your understanding.

Thanks
Gang
> Fixes: a2cbb1603943 ("tcp: Update window clamping condition")
> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/619
> Signed-off-by: Gang Yan <yangang@kylinos.cn>
> ---
> Notes:
> 
> Hi Matt:
> 
> Note that I do not implement set_rcvbuf in mptcp_stream_ops for the 
> following reasons:
> 
>  - The callback receives the MPTCP meta socket as 'sk', but
>  tcp_set_rcvbuf() must be called on each TCP subflow to update
>  window_clamp. A callback implementation would need to iterate all
>  subflows, duplicating the work already done by
>  mptcp_sol_socket_sync_intval().
> 
>  - Subflows are grafted to the MPTCP socket via mptcp_sock_graft(),
>  so ssk->sk_socket->ops points to mptcp_stream_ops, not
>  inet_stream_ops. This means the TCP set_rcvbuf callback is not
>  reachable through the subflow's ops either.
> 
>  - The existing subflow sync functions cover both the setsockopt path
>  (mptcp_sol_socket_sync_intval) and new subflow creation path
>  (sync_socket_options), making the proto_ops callback unnecessary.
> 
> WDYT?
> 
> The packetdrill tests is also implemented:
>  -Link: https://github.com/multipath-tcp/packetdrill/pull/194
> 
> Thanks
> Gang
> 
> ---
>  net/mptcp/sockopt.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c
> index de90a2897d2d..abe63392826b 100644
> --- a/net/mptcp/sockopt.c
> +++ b/net/mptcp/sockopt.c
> @@ -67,6 +67,12 @@ static int mptcp_get_int_option(struct mptcp_sock *msk, sockptr_t optval,
>  return 0;
>  }
>  
> +static inline void __mptcp_subflow_set_rcvbuf(struct sock *ssk, int val)
> +{
> + WRITE_ONCE(ssk->sk_rcvbuf, val);
> + tcp_set_rcvbuf(ssk, val);
> +}
> +
>  static void mptcp_sol_socket_sync_intval(struct mptcp_sock *msk, int optname, int val)
>  {
>  struct mptcp_subflow_context *subflow;
> @@ -100,7 +106,7 @@ static void mptcp_sol_socket_sync_intval(struct mptcp_sock *msk, int optname, in
>  case SO_RCVBUF:
>  case SO_RCVBUFFORCE:
>  ssk->sk_userlocks |= SOCK_RCVBUF_LOCK;
> - WRITE_ONCE(ssk->sk_rcvbuf, sk->sk_rcvbuf);
> + __mptcp_subflow_set_rcvbuf(ssk, sk->sk_rcvbuf);
>  break;
>  case SO_MARK:
>  if (READ_ONCE(ssk->sk_mark) != sk->sk_mark) {
> @@ -1556,7 +1562,7 @@ static void sync_socket_options(struct mptcp_sock *msk, struct sock *ssk)
>  mptcp_subflow_ctx(ssk)->cached_sndbuf = sk->sk_sndbuf;
>  }
>  if (sk->sk_userlocks & SOCK_RCVBUF_LOCK)
> - WRITE_ONCE(ssk->sk_rcvbuf, sk->sk_rcvbuf);
> + __mptcp_subflow_set_rcvbuf(ssk, sk->sk_rcvbuf);
>  }
>  
>  if (sock_flag(sk, SOCK_LINGER)) {
> -- 
> 2.43.0
>

      reply	other threads:[~2026-04-16 12:33 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-16 12:29 [PATCH mptcp-net] mptcp: update window_clamp on subflows when SO_RCVBUF is set Gang Yan
2026-04-16 12:33 ` gang.yan [this message]

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=b5e178f01d0f9523d48d163a56488756ce20450f@linux.dev \
    --to=gang.yan@linux.dev \
    --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.