Hi, On Fri, 2020-05-22 at 14:43 +0200, Florian Westphal wrote: > TCP does tcp rcvbuf tuning when copying packets to userspace, e.g. in > tcp_read_sock(). In case of mptcp, that function is only rarely used > (when discarding retransmitted duplicate data). > > Instead, skbs are moved from the tcp rx queue to the mptcp socket rx > queue. > Adjust subflow rcvbuf when we do so, its the last spot where we can > adjust the ssk rcvbuf -- later we only have the mptcp-level socket. > > This greatly improves performance on mptcp bulk transfers. > > Signed-off-by: Florian Westphal <f...@strlen.de> > --- > net/mptcp/protocol.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c > index ba9d3d5c625f..dbb86cbb9e77 100644 > --- a/net/mptcp/protocol.c > +++ b/net/mptcp/protocol.c > @@ -248,6 +248,9 @@ static bool __mptcp_move_skbs_from_subflow(struct > mptcp_sock *msk, > > *bytes = moved; > > + if (moved) > + tcp_rcv_space_adjust(ssk); > + > return done; > }
It looks like this way ssk rcvbuf will grow up to tcp_rmem[2] even if there is no user-space reader - assuming the link is fast enough. Don't we need to somehow cap that? e.g. moving mptcp rcvbuf update in mptcp_revmsg()? Thanks, Paolo
