From patchwork Thu Feb 5 17:10:05 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Dumazet X-Patchwork-Id: 5785741 Return-Path: X-Original-To: patchwork-linux-wireless@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 5D484BF440 for ; Thu, 5 Feb 2015 17:10:28 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 7CB9520218 for ; Thu, 5 Feb 2015 17:10:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9A60C201FB for ; Thu, 5 Feb 2015 17:10:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758250AbbBERKT (ORCPT ); Thu, 5 Feb 2015 12:10:19 -0500 Received: from mail-ig0-f181.google.com ([209.85.213.181]:62516 "EHLO mail-ig0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754169AbbBERKQ (ORCPT ); Thu, 5 Feb 2015 12:10:16 -0500 Received: by mail-ig0-f181.google.com with SMTP id hn18so14793577igb.2; Thu, 05 Feb 2015 09:10:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=BM6RlGQJKDMvid3GiHm0hCIYFaxFuIU99iQvv5/WSFs=; b=VpzrsQG+Eqyq1IVANYIKLC71SaV5siy4Jd/LwQNyud/aVJL6hRKu59je7vAk2ssRrT 3HmVbh9COqD3YyjssmHWn8h6HVwN94rUTv2jiaQ6FGy6zjOiONL8AijVoLQvbuTcqJXM 99AdFILVQDf8zWQZVbiKsUdSo3kIYKbp28rOEhD5ZDHr8Rrak5+WeyZo2S1N/ar+BCYb Vdn0Oi81xTfDhD7MvHyXdPuiIkt+NZn+4Vmm52y2rNpp2Lwk5M6IeIaipvPncOMhaCzt AY9xR3lAHQEhst6vucZHRAkdomFQch4e9EWf/dA2Fg27m0iSEoFuYPDw+PFvcI7Bc1vM S8rw== X-Received: by 10.50.79.135 with SMTP id j7mr31866459igx.32.1423156207388; Thu, 05 Feb 2015 09:10:07 -0800 (PST) Received: from [172.19.248.118] ([172.19.248.118]) by mx.google.com with ESMTPSA id y6sm2256907iod.32.2015.02.05.09.10.05 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128); Thu, 05 Feb 2015 09:10:06 -0800 (PST) Message-ID: <1423156205.31870.86.camel@edumazet-glaptop2.roam.corp.google.com> Subject: Re: Throughput regression with `tcp: refine TSO autosizing` From: Eric Dumazet To: Michal Kazior Cc: Neal Cardwell , linux-wireless , Network Development , eyalpe@dev.mellanox.co.il Date: Thu, 05 Feb 2015 09:10:05 -0800 In-Reply-To: <1423147286.31870.59.camel@edumazet-glaptop2.roam.corp.google.com> References: <1422537297.21689.15.camel@edumazet-glaptop2.roam.corp.google.com> <1422628835.21689.95.camel@edumazet-glaptop2.roam.corp.google.com> <1422903136.21689.114.camel@edumazet-glaptop2.roam.corp.google.com> <1422926330.21689.138.camel@edumazet-glaptop2.roam.corp.google.com> <1422973660.907.10.camel@edumazet-glaptop2.roam.corp.google.com> <1423051045.907.108.camel@edumazet-glaptop2.roam.corp.google.com> <1423053531.907.115.camel@edumazet-glaptop2.roam.corp.google.com> <1423055810.907.125.camel@edumazet-glaptop2.roam.corp.google.com> <1423056591.907.130.camel@edumazet-glaptop2.roam.corp.google.com> <1423084303.31870.15.camel@edumazet-glaptop2.roam.corp.google.com> <1423141038.31870.38.camel@edumazet-glaptop2.roam.corp.google.com> <1423142342.31870.49.camel@edumazet-glaptop2.roam.corp.google.com> <1423147286.31870.59.camel@edumazet-glaptop2.roam.corp.google.com> X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, T_DKIM_INVALID, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Thu, 2015-02-05 at 06:41 -0800, Eric Dumazet wrote: > Not at all. This basically removes backpressure. > > A single UDP socket can now blast packets regardless of SO_SNDBUF > limits. > > This basically remove years of work trying to fix bufferbloat. > > I still do not understand why increasing tcp_limit_output_bytes is not > working for you. Oh well, tcp_limit_output_bytes might be ok. In fact, the problem comes from GSO assumption. Maybe Herbert was right, when he suggested TCP would be simpler if we enforced GSO... When GSO is used, the thing works because 2*skb->truesize is roughly 2 ms worth of traffic. Because you do not use GSO, and tx completions are slow, we need this : --- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c index 65caf8b95e17..ac01b4cd0035 100644 --- a/net/ipv4/tcp_output.c +++ b/net/ipv4/tcp_output.c @@ -2044,7 +2044,8 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle, break; /* TCP Small Queues : - * Control number of packets in qdisc/devices to two packets / or ~1 ms. + * Control number of packets in qdisc/devices to two packets / + * or ~2 ms (sk->sk_pacing_rate >> 9) in case GSO is off. * This allows for : * - better RTT estimation and ACK scheduling * - faster recovery @@ -2053,7 +2054,7 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle, * of queued bytes to ensure line rate. * One example is wifi aggregation (802.11 AMPDU) */ - limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 10); + limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 9); limit = min_t(u32, limit, sysctl_tcp_limit_output_bytes); if (atomic_read(&sk->sk_wmem_alloc) > limit) {