From patchwork Fri Feb 2 16:55:16 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "dpreed@deepplum.com" X-Patchwork-Id: 10197917 X-Patchwork-Delegate: johannes@sipsolutions.net Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 1D21560388 for ; Fri, 2 Feb 2018 18:27:50 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0CFCF288ED for ; Fri, 2 Feb 2018 18:27:50 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 0162228C00; Fri, 2 Feb 2018 18:27:49 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 38C6D288ED for ; Fri, 2 Feb 2018 18:27:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754743AbeBBS0J convert rfc822-to-8bit (ORCPT ); Fri, 2 Feb 2018 13:26:09 -0500 Received: from smtp86.iad3a.emailsrvr.com ([173.203.187.86]:57956 "EHLO smtp86.iad3a.emailsrvr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752726AbeBBRBq (ORCPT ); Fri, 2 Feb 2018 12:01:46 -0500 X-Greylist: delayed 389 seconds by postgrey-1.27 at vger.kernel.org; Fri, 02 Feb 2018 12:01:46 EST Received: from smtp35.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp35.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id F23845C5F; Fri, 2 Feb 2018 11:55:16 -0500 (EST) X-SMTPDoctor-Processed: csmtpprox beta Received: from smtp35.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp35.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id EDFB15C2F; Fri, 2 Feb 2018 11:55:16 -0500 (EST) Received: from app62.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp35.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id CA4F55A6B; Fri, 2 Feb 2018 11:55:16 -0500 (EST) X-Sender-Id: dpreed@deepplum.com Received: from app62.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Fri, 02 Feb 2018 11:55:16 -0500 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app62.wa-webapps.iad3a (Postfix) with ESMTP id B5F2C4130B; Fri, 2 Feb 2018 11:55:16 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Fri, 2 Feb 2018 11:55:16 -0500 (EST) X-Auth-ID: dpreed@deepplum.com Date: Fri, 2 Feb 2018 11:55:16 -0500 (EST) Subject: RE: [Make-wifi-fast] [PATCH] mac80211: Adjust TSQ pacing shift From: "dpreed@deepplum.com" To: make-wifi-fast@lists.bufferbloat.net, linux-wireless@vger.kernel.org MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: <20180202151105.30043-1-toke@toke.dk> References: <20180202151105.30043-1-toke@toke.dk> Message-ID: <1517590516.742814797@apps.rackspace.com> X-Mailer: webmail/12.11.0-RC Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP I'm curious about the "WiFi Aware" initiative by the WiFi Alliance. Does LEDE and/or Linux support this protocol? I know gSupplicant is potentially the way such things are supposed to work, at least according to its supporters. The general NAN (Neighborhood-Aware-Networking) concept makes a lot of sense at one level, but as an Internet guy, it troubles me that they decided to split from the Internet and go a balkanized direction. To me, the neighborhood is interesting only as part of a larger Internet. It also troubles me that WiFi Aware is a "certification program" rather than a real standard. -----Original Message----- From: "Toke Høiland-Jørgensen" Sent: Friday, February 2, 2018 10:11am To: make-wifi-fast@lists.bufferbloat.net, linux-wireless@vger.kernel.org Cc: "Toke Høiland-Jørgensen" Subject: [Make-wifi-fast] [PATCH] mac80211: Adjust TSQ pacing shift Since we now have the convenient helper to do so, actually adjust the TSQ pacing shift for packets going out over a WiFi interface. This significantly improves throughput for locally-originated TCP connections. The default pacing shift of 10 corresponds to ~1ms of queued packet data. Adjusting this to a shift of 8 (i.e. ~4ms) improves 1-hop throughput for ath9k by a factor of 3, whereas increasing it more has diminishing returns. Achieved throughput for different values of sk_pacing_shift (average of 5 iterations of 10-sec netperf runs to a host on the other side of the WiFi hop): sk_pacing_shift 10: 43.21 Mbps (pre-patch) sk_pacing_shift 9: 78.17 Mbps sk_pacing_shift 8: 123.94 Mbps sk_pacing_shift 7: 128.31 Mbps Latency for competing flows increases from ~3 ms to ~10 ms with this change. This is about the same magnitude of queueing latency induced by flows that are not originated on the WiFi device itself (and so are not limited by TSQ). Signed-off-by: Toke Høiland-Jørgensen --- net/mac80211/tx.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c index 25904af38839..69722504e3e1 100644 --- a/net/mac80211/tx.c +++ b/net/mac80211/tx.c @@ -3574,6 +3574,14 @@ void __ieee80211_subif_start_xmit(struct sk_buff *skb, if (!IS_ERR_OR_NULL(sta)) { struct ieee80211_fast_tx *fast_tx; + /* We need a bit of data queued to build aggregates properly, so + * instruct the TCP stack to allow more than a single ms of data + * to be queued in the stack. The value is a bit-shift of 1 + * second, so 8 is ~4ms of queued data. Only affects local TCP + * sockets. + */ + sk_pacing_shift_update(skb->sk, 8); + fast_tx = rcu_dereference(sta->fast_tx); if (fast_tx &&