From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 70E0E3B25D; Mon, 16 May 2016 10:23:07 -0400 (EDT) Received: by mail-pf0-x22c.google.com with SMTP id 206so68529157pfu.0; Mon, 16 May 2016 07:23:07 -0700 (PDT) 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 :mime-version:content-transfer-encoding; bh=tdxZpkVAEL4iHiN+UL+JnmrDXRvrIxeKvaYNP9iKnq8=; b=uUNBJCE/iHrAVjoZG25uPCnoWN2r17xjsTA5Ea3BhzzF0Y1h90boKX9BZTeSpRDtwz IdxEmlbMhXM2tpVeQlXFXenv8shbvHJ8tsFm4p485aq57vRMp9pvleMIVUvYEBF3Finu FfvC0xsO2lYxLiHGGxXj+PKcEagr4HphiY921ME8v22rym52PQYt0O6cUtFPFeToHfmI +wW5IbqAVKftV3Xgn6KCkd28QfBxennJlTBKU8poXCXj/eeerhSeJP3T0duNe4HEOvGo h5g6mb8sBgwieK4hfqcKzr7UQHybPl1SnV5m3DlBsge3WhwkfSCQvK2BvvfhhXR0f5I+ ugCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=tdxZpkVAEL4iHiN+UL+JnmrDXRvrIxeKvaYNP9iKnq8=; b=a9Hg2QKY9aOsTtGusZcRRmZI00RB/EZwBmEZB66QtxUtYkSlSex9xyBhWF3GBjkX5z UnVJMBLFHIS0/jqRsMouDI8nBrIe2wg7qqg2kBdXmhgXw+meHypkZXj77My2BIp2mITo iAoL1no9LE0EQ16QieZ40hAfqxDyUxdZJouKS1TNSMTutqtVvRJYD2BMS/hWddqyv1Yo ggcdSKnM2Ny+VLcGcl9zWWVtnpBnuozZV0ilnRf4gTP2h0UxkVLrJbLwSTcV/hlTzfUv kM+xInSWHKvrTrWEcd2Vrcq+vcOG5NNdqbVJoIAH5lcure0RocaoqkbcFmD+9ZsM2yLw AfzQ== X-Gm-Message-State: AOPr4FUxKlLbwIJ8vwFAnnd8oqGd2jLi5mstYwg3OZ917fIl66GEYXjPx6uIM04UOj2H5Q== X-Received: by 10.98.96.194 with SMTP id u185mr45463797pfb.13.1463408586591; Mon, 16 May 2016 07:23:06 -0700 (PDT) Received: from [192.168.10.102] ([207.198.105.19]) by smtp.googlemail.com with ESMTPSA id t8sm47929983paw.16.2016.05.16.07.23.03 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 May 2016 07:23:05 -0700 (PDT) Message-ID: <1463408582.18194.84.camel@edumazet-glaptop3.roam.corp.google.com> From: Eric Dumazet To: Roman Yeryomin Cc: Rajkumar Manoharan , Michal Kazior , make-wifi-fast@lists.bufferbloat.net, =?UTF-8?Q?Rafa=C5=82_Mi=C5=82ecki?= , ath10k , "netdev@vger.kernel.org" , "codel@lists.bufferbloat.net" , OpenWrt Development List , Felix Fietkau Date: Mon, 16 May 2016 07:23:02 -0700 In-Reply-To: References: <1462125592.5535.194.camel@edumazet-glaptop3.roam.corp.google.com> <865DA393-262D-40B6-A9D3-1B978CD5F6C6@gmail.com> <1462128385.5535.200.camel@edumazet-glaptop3.roam.corp.google.com> <1462136140.5535.219.camel@edumazet-glaptop3.roam.corp.google.com> <1462201620.5535.250.camel@edumazet-glaptop3.roam.corp.google.com> <1462205669.5535.254.camel@edumazet-glaptop3.roam.corp.google.com> <1462464776.13075.18.camel@edumazet-glaptop3.roam.corp.google.com> <1462476207.13075.20.camel@edumazet-glaptop3.roam.corp.google.com> <20160506114243.4eb4f95e@redhat.com> <20160506144740.210901f5@redhat.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood) X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 14:23:07 -0000 On Mon, 2016-05-16 at 11:14 +0300, Roman Yeryomin wrote: > So, very close to "as before": 900Mbps UDP, 750 TCP. > But still, I was expecting performance improvements from latest ath10k > code, not regressions. > I know that hw is capable of 800Mbps TCP, which I'm targeting. One flow can reach 800Mbps. To get this, a simple pfifo is enough. But _if_ you also want to get decent results with hundreds of flows under stress, you need something else, and I do not see how 'something' else would come for free. You will see some 'regressions' because of additional cpu costs, unless you have enough cpu cycles and KB of memory to burn for free. If your goal is to get max throughput on a single TCP flow, in a clean env an cheap hardware, you absolutely should stick to pfifo. Nothing could beat pfifo (well, pfifo could be improved using lockless implementation, but that would matter if you have different cpus queueing and dequeueing packets) But I guess your issues mostly come from a too small packet limits, or to big TCP windows. Basically, if you test a single TCP flow, fq_codel should behave like a pfifo, unless maybe your kernel has a very slow ktime_get_ns() implementation [1] If you set a limit of 1024 packets on pfifo, you'll have the same amount of drops and lower TCP throughput. [1] We probably should have a self-test to have an estimation of ktime_get_ns() cost