From: Florian Westphal <fw@strlen•de>
To: Christoph Paasch <christoph.paasch@gmail•com>
Cc: Florian Westphal <fw@strlen•de>, netdev <netdev@vger•kernel.org>,
Matthieu Baerts <matthieu.baerts@tessares•net>,
Mat Martineau <mathew.j.martineau@linux•intel.com>,
Paolo Abeni <pabeni@redhat•com>
Subject: Re: [PATCH v2 net-next 2/2] mptcp: move recbuf adjustment to recvmsg path
Date: Wed, 27 May 2020 13:55:17 +0200 [thread overview]
Message-ID: <20200527115517.GG2915@breakpoint.cc> (raw)
In-Reply-To: <CALMXkpa8iryjBDu0dpduHnZXROwT5xWWY9rifau93gDE1HJsxg@mail.gmail.com>
Christoph Paasch <christoph.paasch@gmail•com> wrote:
> tcp_rcv_space_adjust is called even when the app is not yet reading,
> thus wouldn't this mean that we still end up with an ever-growing
> window?
Window is based on available mptcp sk recvbuf. When data is moved from
ssk to the mptcp sk, the skb truesize is charged to the mptcp rmem.
> E.g., imagine an app that does not read at all at the beginning. The
> call to tcp_rcv_space_adjust in patch 1/2 will make the subflow's
> window grow. Now, the app comes and reads one byte. Then, the window
> at MPTCP-level will jump regardless of how much the app actually read.
Yes, the rcvbufsz value will jump, regardless homw much the app
actually read.
> I think what is needed is to size the MPTCP-level window to 2 x the
> amount of data read by the application within an RTT (maximum RTT
> among all the active subflows). That way if an app reads 1 byte a
> second, the window will remain low. While for a bulk-transfer it will
> allow all subflows to receive at full speed [1].
Sounds like the idea to move skbs to msk was bad one?
Sorry, I don't see how I can make this work.
Even deferring tcp_rcv_space_adjust() until recv() time won't work,
given data has been pulled to the mptcp socket already.
NOT calling tcp_rcv_space_adjust() at all might work, but that would
require something else entirely. We would still have to adjust the
subflow rcvbufsz in this case, else we may announce a window that is
larger than the memory limit of the ssk (and we will end up dropping
data at tcp level if the worker can't move the skbs fast enough).
> Or do you think that kind of tuning can be done in a follow-up patch?
This sounds completely different so I don't think that makes sense.
next prev parent reply other threads:[~2020-05-27 11:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-25 18:15 [PATCH v2 net-next 0/2] mptcp: adjust tcp rcvspace on rx Florian Westphal
2020-05-25 18:15 ` [PATCH v2 net-next 1/2] mptcp: adjust tcp rcvspace after moving skbs from ssk to sk queue Florian Westphal
2020-05-25 18:15 ` [PATCH v2 net-next 2/2] mptcp: move recbuf adjustment to recvmsg path Florian Westphal
2020-05-26 16:07 ` Christoph Paasch
2020-05-27 11:55 ` Florian Westphal [this message]
2020-05-27 3:28 ` [PATCH v2 net-next 0/2] mptcp: adjust tcp rcvspace on rx David Miller
2020-05-27 11:55 ` Florian Westphal
2020-05-27 18:29 ` David Miller
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=20200527115517.GG2915@breakpoint.cc \
--to=fw@strlen$(echo .)de \
--cc=christoph.paasch@gmail$(echo .)com \
--cc=mathew.j.martineau@linux$(echo .)intel.com \
--cc=matthieu.baerts@tessares$(echo .)net \
--cc=netdev@vger$(echo .)kernel.org \
--cc=pabeni@redhat$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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