DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 59841206B7
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date:   Fri, 28 Sep 2018 12:51:06 -0700
From:   Rajkumar Manoharan <rmanohar@codeaurora.org>
To:     =?UTF-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= <toke@toke.dk>
Cc:     Jonathan Morton <chromatix99@gmail.com>, Kan Yan <kyan@google.com>,
        make-wifi-fast@lists.bufferbloat.net,
        linux-wireless-owner@vger.kernel.org,
        linux-wireless@vger.kernel.org, Felix Fietkau <nbd@nbd.name>
Subject: Re: [Make-wifi-fast] [PATCH RFC v4 3/4] mac80211: Add airtime
 accounting and scheduling to TXQs
In-Reply-To: <4929C006-3452-4C17-9500-8D7485EB538E@toke.dk>
References: <153711966150.9231.13481453399723518107.stgit@alrua-x1>
 <153711973134.9231.18038849900399644494.stgit@alrua-x1.karlstad.toke.dk>
 <826b6251746ee4d280d532f4ecdc5aa3@codeaurora.org> <87pnx0haud.fsf@toke.dk>
 <8f7145bf5abe50194bced025a5e739b9@codeaurora.org>
 <863bc54fbf04441d38dd53f523300a7e@codeaurora.org>
 <93015743-5D16-4D79-948F-E2F46CF2450A@toke.dk>
 <7ba8513b0ec5a7c35b396c7739fc2d7d@codeaurora.org> <87zhw2eyfo.fsf@toke.dk>
 <5d961a5f61de45b85b1b037bcef9270d@codeaurora.org>
 <44B09168-C08F-4C85-8D74-D576CCC79880@gmail.com>
 <586459da6ec36edc2284df8533915d62@codeaurora.org>
 <4929C006-3452-4C17-9500-8D7485EB538E@toke.dk>
Message-ID: <34effd2ca6423b33e3871de99022d757@codeaurora.org>
User-Agent: Roundcube Webmail/1.2.5
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

On 2018-09-28 04:02, Toke Høiland-Jørgensen wrote:
> On 28 September 2018 12:47:51 CEST, Rajkumar Manoharan
> <rmanohar@codeaurora.org> wrote:
>> On 2018-09-28 03:35, Jonathan Morton wrote:
>>>> On 28 Sep, 2018, at 1:19 pm, Rajkumar Manoharan
>>>> <rmanohar@codeaurora.org> wrote:
>>>> 
>>>>> This is going to break fairness; we only want to increase deficits
>>>>> when
>>>>> all stations' deficits are negative. Hence the two loops. Did you
>> see
>>>>> any problems with those specifically?
>>>> 
>>>> No. I didn't see any issue but the loop won't exit until one txq
>>>> becomes positive.
>>>> Till then the lock won't be released. Hence I converged into single
>>>> iteration.
>>> 
>>> The problem is that the fairness behaviour is changed when there are
>>> already positive txqs, but the first one happens to not be positive.
>>> That's why there were two loops.
>>> 
>> Yeah.. Understood. we can ignore the cleanup change.
> 
> Great! I'll fold in the rest, test it with ath9k and submit as a proper 
> patch :)
> 
Thanks. I am seeing higher CPU load. Did you observe similar behavior 
with ath9k.

-Rajkumar