tipc: fix large latency in smart Nagle streaming
authorTuong Lien <tuong.t.lien@dektech.com.au>
Wed, 13 May 2020 12:33:16 +0000 (19:33 +0700)
committerDavid S. Miller <davem@davemloft.net>
Wed, 13 May 2020 19:33:18 +0000 (12:33 -0700)
commitc72685894506a3fec5978b9b11b94069a7d1c995
treeb6a136b7504654b0f4a49bf1fa60105662ff4c1e
parentf3fbc5a38021637aa959a04239d7ef921a7336bc
tipc: fix large latency in smart Nagle streaming

Currently when a connection is in Nagle mode, we set the 'ack_required'
bit in the last sending buffer and wait for the corresponding ACK prior
to pushing more data. However, on the receiving side, the ACK is issued
only when application really  reads the whole data. Even if part of the
last buffer is received, we will not do the ACK as required. This might
cause an unnecessary delay since the receiver does not always fetch the
message as fast as the sender, resulting in a large latency in the user
message sending, which is: [one RTT + the receiver processing time].

The commit makes Nagle ACK as soon as possible i.e. when a message with
the 'ack_required' arrives in the receiving side's stack even before it
is processed or put in the socket receive queue...
This way, we can limit the streaming latency to one RTT as committed in
Nagle mode.

Acked-by: Ying Xue <ying.xue@windriver.com>
Acked-by: Jon Maloy <jmaloy@redhat.com>
Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
net/tipc/socket.c