Re: [PATCH mptcp-net] mptcp: sync the msk->sndbuf at accept() time

[GangYan <gang.yan@linux.dev>]

> On Fri, Nov 28, 2025 at 03:53:54PM +0100, Paolo Abeni wrote:
> On 11/28/25 10:44 AM, Gang Yan wrote:
> > From: Gang Yan <yangang@kylinos.cn>
> >
Hi Paoto,
So glad to receive your messages.

> > After an MPTCP connection is established, the sk_sndbuf of client's msk
> > can be updated through 'subflow_finish_connect'. However, the newly
> > accepted msk on the server side has a small sk_sndbuf than
> > msk->first->sk_sndbuf:
> > 
> > '''
> > MPTCP: msk:00000000e55b09db, msk->sndbuf:20480, msk->first->sndbuf:2626560
> > '''
> 
> How do you observe the above exactly? subflow-level rcvbuf increases -
I observe this through an normal test, using server to send MSG DONTWAIT messages
to the client once the connection is established.
In fact, we can use the 'send_recv_data'’in mptcp's bpfselftest with
MSG DONTWAIT flag.

> in tcp_new_space() -  are propagated to the msk via:
> 
> ssk->sk_write_space -> subflow_write_space -> mptcp_propagate_sndbuf.
>
Yes, but the 'tcp_sndbuf_extend' also called in 'tcp_init_buffer_space'
immediately after connection enters established state. The client side is updated
via: "subflow_finish_connect' -> 'mptcp propagate_state'. But the server side 
seems need to update msk->sk_sndbuf too. 
> > This means that when the server immediately sends MSG_DONTWAIT data to
> > the client after the connection is established, it is more likely to
> > encounter EAGAIN.
> 
> It's unclear to me how the subflow rcvbuf can be greater than default
> before sending any data.
I raised an issue in multpath-tcp/mptcp-net-next, and post some information here,
maybe it is helpful;
https://github.com/multipath-tcp/mptcp_net-next/1ssues/602

Thanks
Gang
> 
> /P
> 
>