]> git.baikalelectronics.ru Git - kernel.git/commit
Merge branch 'mptcp-update-mptcp-ack-sequence-outside-of-recv-path'
authorDavid S. Miller <davem@davemloft.net>
Thu, 27 Feb 2020 04:46:26 +0000 (20:46 -0800)
committerDavid S. Miller <davem@davemloft.net>
Thu, 27 Feb 2020 04:46:26 +0000 (20:46 -0800)
commit83988d37abc922342d3f35aedb7d37fbf3a381ff
tree1e909ad2d71b864e798e2f14838dd756c398dad1
parentc7aeec0acb9b4566c4062195522c5e420987bc10
parent93f8af505a270e515b09dda8a9f0f1107eea165d
Merge branch 'mptcp-update-mptcp-ack-sequence-outside-of-recv-path'

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>