summaryrefslogtreecommitdiffstats
path: root/net/ieee802154
diff options
context:
space:
mode:
authorTuong Lien <tuong.t.lien@dektech.com.au>2020-05-13 19:33:16 +0700
committerDavid S. Miller <davem@davemloft.net>2020-05-13 12:33:18 -0700
commitc72685894506a3fec5978b9b11b94069a7d1c995 (patch)
treeb6a136b7504654b0f4a49bf1fa60105662ff4c1e /net/ieee802154
parentf3fbc5a38021637aa959a04239d7ef921a7336bc (diff)
downloadlinux-c72685894506a3fec5978b9b11b94069a7d1c995.tar.bz2
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>
Diffstat (limited to 'net/ieee802154')
0 files changed, 0 insertions, 0 deletions