From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH net-next] tcp: allow TLP in ECN CWR Date: Wed, 13 Dec 2017 13:59:37 -0500 (EST) Message-ID: <20171213.135937.1164115023745684468.davem@davemloft.net> References: <20171211234253.102924-1-ycheng@google.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, ncardwell@google.com, edumazet@google.com, nanditad@google.com, sibanez@stanford.edu To: ycheng@google.com Return-path: Received: from shards.monkeyblade.net ([184.105.139.130]:42826 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753154AbdLMS7i (ORCPT ); Wed, 13 Dec 2017 13:59:38 -0500 In-Reply-To: <20171211234253.102924-1-ycheng@google.com> Sender: netdev-owner@vger.kernel.org List-ID: From: Yuchung Cheng Date: Mon, 11 Dec 2017 15:42:53 -0800 > From: Neal Cardwell > > This patch enables tail loss probe in cwnd reduction (CWR) state > to detect potential losses. Prior to this patch, since the sender > uses PRR to determine the cwnd in CWR state, the combination of > CWR+PRR plus tcp_tso_should_defer() could cause unnecessary stalls > upon losses: PRR makes cwnd so gentle that tcp_tso_should_defer() > defers sending wait for more ACKs. The ACKs may not come due to > packet losses. > > Disallowing TLP when there is unused cwnd had the primary effect > of disallowing TLP when there is TSO deferral, Nagle deferral, > or we hit the rwin limit. Because basically every application > write() or incoming ACK will cause us to run tcp_write_xmit() > to see if we can send more, and then if we sent something we call > tcp_schedule_loss_probe() to see if we should schedule a TLP. At > that point, there are a few common reasons why some cwnd budget > could still be unused: > > (a) rwin limit > (b) nagle check > (c) TSO deferral > (d) TSQ > > For (d), after the next packet tx completion the TSQ mechanism > will allow us to send more packets, so we don't really need a > TLP (in practice it shouldn't matter whether we schedule one > or not). But for (a), (b), (c) the sender won't send any more > packets until it gets another ACK. But if the whole flight was > lost, or all the ACKs were lost, then we won't get any more ACKs, > and ideally we should schedule and send a TLP to get more feedback. > In particular for a long time we have wanted some kind of timer for > TSO deferral, and at least this would give us some kind of timer > > Reported-by: Steve Ibanez > Signed-off-by: Neal Cardwell > Signed-off-by: Yuchung Cheng > Reviewed-by: Nandita Dukkipati > Reviewed-by: Eric Dumazet Applied, thanks.