From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.codeaurora.org (smtp.codeaurora.org [198.145.29.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E44513B25D for ; Mon, 22 Aug 2016 13:02:22 -0400 (EDT) Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 04B7361C43; Mon, 22 Aug 2016 17:02:21 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=ALL_TRUSTED,BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from potku.adurom.net (a88-115-185-251.elisa-laajakaista.fi [88.115.185.251]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kvalo@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id EBBA561C0E; Mon, 22 Aug 2016 17:02:19 +0000 (UTC) From: Kalle Valo To: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= Cc: linux-wireless@vger.kernel.org, make-wifi-fast@lists.bufferbloat.net, ath9k-devel@lists.ath9k.org, Tim Shepard , Felix Fietkau References: <20160706193417.13080-1-toke@toke.dk> <20160805160346.10545-1-toke@toke.dk> <87mvk44xmt.fsf@purkki.adurom.net> <87bn0k4w4d.fsf@toke.dk> In-Reply-To: <87bn0k4w4d.fsf@toke.dk> ("Toke =?utf-8?Q?H=C3=B8iland-J?= =?utf-8?Q?=C3=B8rgensen=22's?= message of "Mon, 22 Aug 2016 18:16:34 +0200") Message-ID: <87fupwvisn.fsf@kamboji.qca.qualcomm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 28 Nov 2016 08:47:10 -0500 Subject: Re: [Make-wifi-fast] [PATCH v4] ath9k: Switch to using mac80211 intermediate software queues. 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: , Date: Mon, 22 Aug 2016 17:02:23 -0000 X-Original-Date: Mon, 22 Aug 2016 20:02:16 +0300 X-List-Received-Date: Mon, 22 Aug 2016 17:02:23 -0000 Toke H=C3=B8iland-J=C3=B8rgensen writes: > Kalle Valo writes: > >> Toke H=C3=B8iland-J=C3=B8rgensen writes: >> >>> This switches ath9k over to using the mac80211 intermediate software >>> queueing mechanism for data packets. It removes the queueing inside the >>> driver, except for the retry queue, and instead pulls from mac80211 when >>> a packet is needed. The retry queue is used to store a packet that was >>> pulled but can't be sent immediately. >>> >>> The old code path in ath_tx_start that would queue packets has been >>> removed completely, as has the qlen limit tunables (since there's no >>> longer a queue in the driver to limit). >>> >>> Based on Tim's original patch set, but reworked quite thoroughly. >>> >>> Cc: Tim Shepard >>> Cc: Felix Fietkau >>> Signed-off-by: Toke H=C3=B8iland-J=C3=B8rgensen >>> --- >>> Changes since v3 (most due to Felix; thanks!): >>> - Correctly notify mac80211 when there are packets in the retry queue >>> on powersave start/stop. >>> - Get rid of ath_tx_aggr_resume(). >>> - Some readability changes and additional WARN_ON/BUG_ON in >>> appropriate places. >> >> This is great work but due to the regressions I'm not sure if this >> will be ready for 4.9. To get more testing time I wonder if we should >> wait for 4.10? IMHO applying this in the end of the cycle is too risky >> and we should try to maximise the time linux-next by applying this >> just after -rc1 is released. >> >> Thoughts? > > Well, now that we understand what is causing the throughput regressions, > fixing them should be fairly straight forward (yeah, famous last words, > but still...). I already have a patch for the fast path and will go poke > at the slow path next. It'll probably require another workaround or two, > so I guess it won't be the architecturally clean ideal solution; but it > would make it possible to have something that works for 4.9 and then > iterate for a cleaner design for 4.10. But if we try to rush this to 4.9 it won't be in linux-next for long. We are now in -rc3 and let's say that the patches are ready to apply in two weeks. That would leave us only two weeks of -next time before the merge window, which I think is not enough for a controversial patch like this one. There might be other bugs lurking which haven't been found yet. --=20 Kalle Valo