Florian Westphal says:
====================
mptcp: update mptcp ack sequence outside of recv path
This series moves mptcp-level ack sequence update outside of the recvmsg path.
Current approach has two problems:
1. There is delay between arrival of new data and the time we can ack
this data.
2. If userspace doesn't call recv for some time, mptcp ack_seq is not
updated at all, even if this data is queued in the subflow socket
receive queue.
Move skbs from the subflow socket receive queue to the mptcp-level
receive queue, updating the mptcp-level ack sequence and have recv
take skbs from the mptcp-level receive queue.
The first place where we will attempt to update the mptcp level acks
is from the subflows' data_ready callback, even before we make userspace
aware of new data.
Because of possible deadlock (we need to take the mptcp socket lock
while already holding the subflow sockets lock), we may still need to
defer the mptcp-level ack update. In such case, this work will be either
done from work queue or recv path, depending on which runs sooner.
In order to avoid pointless scheduling of the work queue, work
will be queued from the mptcp sockets lock release callback.
This allows to detect when the socket owner did drain the subflow
socket receive queue.
Please see individual patches for more information.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>