Paolo Abeni <pabeni(a)redhat.com> wrote:
On Mon, 2019-09-09 at 17:53 +0200, Florian Westphal wrote:
> This patch series is in need of a bit more work, f.e. there is too much
> copypastry in patch 3.
> However, it is functional as-is so I am sharing it to get earlier reviews.
> Problem with current mptcp_poll() is that we can't block the task on each
> subflow: subflow we're polling on might be idle while another one has data
> ready for processing.
If I read the series correctly, patch 3 is not strictly needed for the
above goal: AFAICS it should help to avoid empty/blocking recvmsg()
after successful poll(), right?
Thats right. EPOLLIN means next recv won't block, which isn't the case
at this time because we do mptcp processing in recv only.
I think we should rework a bit recvmsg() before going on with this -
see "mptcp: partial recvmsg() refactor".
Perhaps even something more
drastic e.g. subflow could try move skbs from ssk->sk_receive_queue to
a per msk queue, ordered by mptcp seq in subflow_data_ready(). WDYT?
Yes, that might be a good idea/needed.
We shouldn't depend on regular recv calls for mptcp processing.