From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 6755C3B25D for ; Mon, 22 Aug 2016 13:13:16 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Filter: OpenDKIM Filter v2.10.3 mail2.tohojo.dk 4CE7B40D5E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1471885993; bh=5d/EVEwD1TuSfPTNwH2oe48nKI6DJeEGGZFejDF5tWk=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=eQjKPm6A8Eow8IHKUUzzbH1qNQsdZlHwVq2x8bpzveRR/MGpZn9eyVswoLbR02AX1 C7rGsLsUBaVM/x63YBid0f9Dxwdc1+oL9pTD6wb97fr5Ga7OLzGw276c95oRBQhzd5 UVZCOMpMnokHHFZMwhvfN6UyqhivzwKN10EgiFCw= Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 57CB061E4; Mon, 22 Aug 2016 19:13:12 +0200 (CEST) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Kalle Valo 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> <87fupwvisn.fsf@kamboji.qca.qualcomm.com> Date: Mon, 22 Aug 2016 19:13:12 +0200 In-Reply-To: <87fupwvisn.fsf@kamboji.qca.qualcomm.com> (Kalle Valo's message of "Mon, 22 Aug 2016 20:02:16 +0300") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <871t1g4thz.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Mon, 22 Aug 2016 17:13:16 -0000 Kalle Valo writes: > 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 wh= en >>>> 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. What, other hidden bugs? Unpossible! :) Would it be possible to merge the partial solution (which is ready now, basically) and fix the slow path in a separate patch later? (Just spit-balling here; I'm still fairly new to this process. But I am concerned that we'll hit a catch-22 where we can't get wider testing before it's "ready" and we can't prove that it's "ready" until we've had wider testing...) -Toke