Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754452AbbEZQYB (ORCPT ); Tue, 26 May 2015 12:24:01 -0400 Received: from mail-ig0-f179.google.com ([209.85.213.179]:32851 "EHLO mail-ig0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752916AbbEZQX5 (ORCPT ); Tue, 26 May 2015 12:23:57 -0400 Message-ID: <1432657435.4060.267.camel@edumazet-glaptop2.roam.corp.google.com> Subject: Re: [PATCH] net: tcp: Fix a PTO timing granularity issue From: Eric Dumazet To: Ido Yariv Cc: "David S. Miller" , Alexey Kuznetsov , James Morris , Hideaki YOSHIFUJI , Patrick McHardy , Nandita Dukkipati , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Ido Yariv Date: Tue, 26 May 2015 09:23:55 -0700 In-Reply-To: <1432650358-11470-1-git-send-email-ido@wizery.com> References: <1432650358-11470-1-git-send-email-ido@wizery.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2336 Lines: 60 On Tue, 2015-05-26 at 10:25 -0400, Ido Yariv wrote: > The Tail Loss Probe RFC specifies that the PTO value should be set to > max(2 * SRTT, 10ms), where SRTT is the smoothed round-trip time. > > The PTO value is converted to jiffies, so the timer might expire > prematurely. This is especially problematic on systems in which HZ=100. > > To work around this issue, increase the number of jiffies by one, > ensuring that the timeout won't expire in less than 10ms. > > Signed-off-by: Ido Yariv > --- > net/ipv4/tcp_output.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c > index 534e5fd..6f57d3d 100644 > --- a/net/ipv4/tcp_output.c > +++ b/net/ipv4/tcp_output.c > @@ -2207,7 +2207,7 @@ bool tcp_schedule_loss_probe(struct sock *sk) > if (tp->packets_out == 1) > timeout = max_t(u32, timeout, > (rtt + (rtt >> 1) + TCP_DELACK_MAX)); > - timeout = max_t(u32, timeout, msecs_to_jiffies(10)); > + timeout = max_t(u32, timeout, msecs_to_jiffies(10) + 1); > > /* If RTO is shorter, just schedule TLP in its place. */ > tlp_time_stamp = tcp_time_stamp + timeout; Have you really hit an issue, or did you send this patch after all these msecs_to_jiffies() discussions on lkml/netdev ? Not sure this is the right fix. TLP was really tested with an effective min delay of 10ms. Adding 10% for the sake of crazy HZ=100 builds seems a high price. (All recent TCP changes were tested with HZ=1000 BTW ...) diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c index 534e5fdb04c11152bae36f47a786e8b10b823cd3..5321df89af9b59c6727395c489e6f9b2770dcd5e 100644 --- a/net/ipv4/tcp_output.c +++ b/net/ipv4/tcp_output.c @@ -2208,6 +2208,9 @@ bool tcp_schedule_loss_probe(struct sock *sk) timeout = max_t(u32, timeout, (rtt + (rtt >> 1) + TCP_DELACK_MAX)); timeout = max_t(u32, timeout, msecs_to_jiffies(10)); +#if HZ <= 100 + timeout = max_t(u32, timeout, 2); +#endif /* If RTO is shorter, just schedule TLP in its place. */ tlp_time_stamp = tcp_time_stamp + timeout; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/