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 2C6B43B29E for ; Tue, 18 Sep 2018 17:30:14 -0400 (EDT) Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 745756079B; Tue, 18 Sep 2018 21:30:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1537306213; bh=rcXioU2IAQy/sBqP/O5GqVgbsxmQGNof122b2g63vtk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=OsgVDw2nnfsXCsAaKN6qqdlNb69xvyg/5qu/CYhP59uCtginpwpPlAmTKONBxPMZZ EXpNlekeRGNIYyIYfC0Fii+U/EO7aYr2Xv87QMtZPpaNl/AVIVjie2f4C8QcwfrEmx TxXZNmtCO6tkY7B4BwZ59ALfEeJgm5iBAGzDybSM= 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.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id BF3906020A; Tue, 18 Sep 2018 21:30:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1537306212; bh=rcXioU2IAQy/sBqP/O5GqVgbsxmQGNof122b2g63vtk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=XEB46eX+lrZ20m/G4eS/y+CrZBDReVtBA11zGMnTrERJf+HC3f4GSqq/6sQ0luk2C YXAPJ0s8MpUr+3DxkJ7jJDZ1RsXPgf3tepvnGYXFQIhntGb+sGJEPw+kJxFpFQJOLj jJEKmthC5Kp0JgW6D58KWIHi6aBA150PS52cMXUQ= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 18 Sep 2018 14:30:12 -0700 From: Rajkumar Manoharan To: =?UTF-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= Cc: linux-wireless@vger.kernel.org, make-wifi-fast@lists.bufferbloat.net, Felix Fietkau , Kan Yan , linux-wireless-owner@vger.kernel.org In-Reply-To: <87efdq8rn0.fsf@toke.dk> References: <153711966150.9231.13481453399723518107.stgit@alrua-x1> <153711973109.9231.7094211814263758096.stgit@alrua-x1.karlstad.toke.dk> <13400b5f9bdb5e36c6afabd071cc7b0d@codeaurora.org> <87o9cvksiv.fsf@toke.dk> <87efdq8rn0.fsf@toke.dk> Message-ID: <5e2612cbd4ea9f560a63149c599f8587@codeaurora.org> X-Sender: rmanohar@codeaurora.org User-Agent: Roundcube Webmail/1.2.5 Subject: Re: [Make-wifi-fast] [PATCH RFC v4 1/4] mac80211: Add TXQ scheduling API 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: Tue, 18 Sep 2018 21:30:14 -0000 On 2018-09-18 13:41, Toke Høiland-Jørgensen wrote: > Rajkumar Manoharan writes: > >>>> Also an option to add the node at head or tail would be preferred. >>>> If >>>> return_txq adds node at head of list, then it is forcing the driver >>>> to >>>> serve same txq until it becomes empty. Also this will not allow the >>>> driver to send N frames from each txqs. >>> >>> The whole point of this patch set is to move those kinds of decisions >>> out of the driver and into mac80211. The airtime scheduler won't >>> achieve >>> fairness if it allows queues to be queued to the end of the rotation >>> before its deficit turns negative. And obviously there's some lag in >>> this since we're using after-the-fact airtime information. >>> >> Hmm.. As you know ath10k kind of doing fairness by serving fixed >> frames >> from each txq. This approach will be removed from ath10k. >> >>> For ath9k this has not really been a problem in my tests; if the lag >>> turns out to be too great for ath10k (which I suppose is a >>> possibility >>> since we don't get airtime information on every TX-compl), I figure >>> we >>> can use the same estimated airtime value that is used for throttling >>> the >>> queues to adjust the deficit immediately... >>> >> Thats true. I am porting Kan's changes of airtime estimation for each >> msdu for firmware that does not report airtime. > > Right. My thinking with this was that we could put the per-frame > airtime > estimation into ieee80211_tx_dequeue(), which could track the > outstanding airtime and just return NULL if it goes over the threshold. > I think this is fairly straight-forward to do on its own; the biggest > problem is probably finding the space in the mac80211 cb? > > Is this what you are working on porting? Because then I'll wait for > your > patch rather than starting to write this code myself :) > Kind of.. something like below. tx_dequeue(){ compute airtime_est from last_tx_rate if (sta->airtime[ac].deficit < airtime_est) return NULL; dequeue skb and store airtime_est in cb } Unfortunately ath10k is not reporting last_tx_rate in tx_status(). So I also applied this "ath10k: report tx rate using ieee80211_tx_status" change. > This mechanism on its own will get us the queue limiting and latency > reduction goodness for firmwares with deep queues. And for that it can > be completely independent of the airtime fairness scheduler, which can > use the after-tx-compl airtime information to presumably get more > accurate fairness which includes retransmissions etc. > > Now, we could *also* use the ahead-of-time airtime estimation for > fairness; either just as a fallback for drivers that can't get actual > airtime usage information for the hardware, or as an alternative in > cases where it works better for other reasons. But I think that > separating the two in the initial implementation makes more sense; that > will make it easier to experiment with different combinations of the > two. > > Does that make sense? :) > Completely agree. I was thinking of using this as fallback for devices that does not report airtime but tx rate. -Rajkumar