From: Rajkumar Manoharan <rmanohar@codeaurora.org>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
Subject: Re: [PATCH 3/6] mac80211: Add airtime accounting and scheduling to TXQs
Date: Sun, 28 Oct 2018 15:01:41 -0700 [thread overview]
Message-ID: <8fd3524bfe022ccd2a8b61a3314ed32b@codeaurora.org> (raw)
In-Reply-To: <87woq2843q.fsf@toke.dk>
On 2018-10-28 08:48, Toke Høiland-Jørgensen wrote:
> Rajkumar Manoharan <rmanohar@codeaurora.org> writes:
>
>> Yes. I do understand the user can change airtime at anytime but It
>> must be noted that different airtime weight will result in different
>> throughput. IMHO the defaults should not impact current benchmark.
>> Otherwise it will be alarmed as regression later. isn't it?
>
> My point is that if the user has to know the implementation-specific
> limitations of each driver before setting a weight, then it's not a
> particularly friendly API. I think we should be able to do better than
> that...
>
Hmm.. I was trying to balance throughput vs CPU usage. Keeping lower
threshold is causing more lock contention and impacting throughput.
I thought of configuring default airtime_weight from hostapd for
legacy, 11n and 11ac stations.
>> airtime station1(%airtime) station2 station3 station4
>> (Mbps)
>>
>> No ATF 182 168 166 169
>>
>> 4ms 170 (100%) 164 (100%) 185 (100%) 175 (100%)
>>
>> 4ms 277 (70%) 115 (10%) 103 (10%) 105 (10%)
>>
>> 4ms 223 (40%) 214 (40%) 109 (10%) 94 (10%)
>>
>> 4ms 337 (90%) 182 (8%) 23 (1%) 30 (1%)
>
> So this looks like it's doing *something*, but not like it's succeeding
> in achieving the set percentages. Did you check if the actual airtime
> values (in debugfs) corresponds to the configured weights?
>
No. Will check that.
>> The only way to enforce mac80211 ordering in ath10k is to disable pull
>> mode in firmware and always operates in push mode similar to ath9k.
>
> And I assume that is not too likely to happen, or? What is the benefit
> of pull mode at the firmware level?
>
Pull mode mainly required to support MU-MIMO. IMHO both MUMIMO & ATF can
not
co-exist unless both are implemented at host driver. Fixing tx mode in
ath10k
needs firmware reload. By introducing modparam, pull-mode can be
disabled.
-Rajkumar
next prev parent reply other threads:[~2018-10-28 22:01 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-20 11:05 [PATCH 0/6] Move TXQ scheduling and airtime fairness into mac80211 Rajkumar Manoharan
2018-10-20 11:05 ` [PATCH 1/6] mac80211: Add TXQ scheduling API Rajkumar Manoharan
2018-11-09 12:00 ` Johannes Berg
2018-11-09 12:39 ` Toke Høiland-Jørgensen
2018-10-20 11:05 ` [PATCH 2/6] cfg80211: Add airtime statistics and settings Rajkumar Manoharan
2018-10-20 11:05 ` [PATCH 3/6] mac80211: Add airtime accounting and scheduling to TXQs Rajkumar Manoharan
2018-10-26 14:16 ` Toke Høiland-Jørgensen
2018-10-26 23:04 ` Rajkumar Manoharan
2018-10-28 15:48 ` Toke Høiland-Jørgensen
2018-10-28 22:01 ` Rajkumar Manoharan [this message]
2018-10-29 23:50 ` Rajkumar Manoharan
2018-11-02 10:30 ` Toke Høiland-Jørgensen
2018-11-05 8:39 ` Rajkumar Manoharan
2018-11-07 14:53 ` Toke Høiland-Jørgensen
2018-11-07 22:35 ` Rajkumar Manoharan
2018-11-08 13:46 ` Toke Høiland-Jørgensen
2018-10-31 6:17 ` yiboz
2018-10-20 11:05 ` [PATCH 4/6] ath9k: Switch to mac80211 TXQ scheduling and airtime APIs Rajkumar Manoharan
2018-10-20 11:05 ` [PATCH 5/6] ath10k: migrate to mac80211 txq scheduling Rajkumar Manoharan
2018-10-24 8:33 ` Kalle Valo
2018-10-24 18:55 ` Rajkumar Manoharan
2018-10-20 11:05 ` [PATCH 6/6] ath10k: reporting estimated tx airtime for fairness Rajkumar Manoharan
2018-10-24 8:35 ` Kalle Valo
2018-10-21 11:27 ` [PATCH 0/6] Move TXQ scheduling and airtime fairness into mac80211 Toke Høiland-Jørgensen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8fd3524bfe022ccd2a8b61a3314ed32b@codeaurora.org \
--to=rmanohar@codeaurora.org \
--cc=ath10k@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=toke@toke.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).