All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Ryder Lee <ryder.lee@mediatek.com>
Cc: linux-mediatek@lists.infradead.org,
	Lorenzo Bianconi <lorenzo.bianconi@redhat.com>,
	Shayne Chen <shayne.chen@mediatek.com>,
	linux-wireless@vger.kernel.org, Felix Fietkau <nbd@nbd.name>
Subject: Re: [PATCH] mac80211: check ATF flag in ieee80211_next_txq()
Date: Thu, 07 Jan 2021 14:08:29 +0100	[thread overview]
Message-ID: <87a6tkki7m.fsf@toke.dk> (raw)
In-Reply-To: <1609985461.9743.2.camel@mtkswgap22>

Ryder Lee <ryder.lee@mediatek.com> writes:

> On Wed, 2021-01-06 at 16:41 +0100, Toke Høiland-Jørgensen wrote:
>> Felix Fietkau <nbd@nbd.name> writes:
>> 
>> > On 2021-01-06 11:51, Toke Høiland-Jørgensen wrote:
>> >> Ryder Lee <ryder.lee@mediatek.com> writes:
>> >> 
>> >>> The selected txq should be scheduled unconditionally if
>> >>> NL80211_EXT_FEATURE_AIRTIME_FAIRNESS is not set by driver.
>> >>>
>> >>> Also put the sta to the end of the active_txqs list if
>> >>> deficit is negative then move on to the next txq.
>> >> 
>> >> Why is this needed? If the feature is not set, no airtime should ever be
>> >> accounted to the station, and so sta->airtime[txqi->txq.ac].deficit will
>> >> always be 0 - so you're just adding another check that doesn't actually
>> >> change the behaviour, aren't you?
>> >
>> > I think it might make sense to keep airtime reporting even when airtime
>> > fairness is disabled at run time, so this patch makes sense to me.
>> > Instead of this patch, the right place to deal with this would probably
>> > be ieee80211_sta_register_airtime.
>> 
>> When the fairness mechanism is user-disabled I agree it makes sense to
>> still keep the accounting; and in fact that's what
>> ieee80211_sta_register_airtime() already does when the accounting is
>> turned off by way of the airtime_flags field... So don't think anything
>> else is needed there either?
>> 
>> -Toke
>
> Not sure I get this right. Are you talking about local->airtime_flags =
> AIRTIME_USE_TX | AIRTIME_USE_RX ? I think that's different and we still
> need to take NL80211_EXT_FEATURE_AIRTIME_FAIRNESS into account, right?

I just meant that what Felix was asking for (a way *for the user* to
disable airtime fairness while still getting the airtime usage
accounted) is possible by setting those flags. The EXT_FEATURE flag is
meant as a way for the driver to signal to mac80211 that it supports
reporting airtime at all; so ideally it should be a flag that is only
set once.

Going back and reading your initial response it seems like you may be
toggling the flag dynamically in the driver, though? Is this accurate?
And if so, why? Is it not enough for you to fiddle with the
USE_TX/USE_RX flags? :)

-Toke

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Ryder Lee <ryder.lee@mediatek.com>
Cc: Felix Fietkau <nbd@nbd.name>,
	Lorenzo Bianconi <lorenzo.bianconi@redhat.com>,
	Shayne Chen <shayne.chen@mediatek.com>,
	linux-wireless@vger.kernel.org,
	linux-mediatek@lists.infradead.org
Subject: Re: [PATCH] mac80211: check ATF flag in ieee80211_next_txq()
Date: Thu, 07 Jan 2021 14:08:29 +0100	[thread overview]
Message-ID: <87a6tkki7m.fsf@toke.dk> (raw)
In-Reply-To: <1609985461.9743.2.camel@mtkswgap22>

Ryder Lee <ryder.lee@mediatek.com> writes:

> On Wed, 2021-01-06 at 16:41 +0100, Toke Høiland-Jørgensen wrote:
>> Felix Fietkau <nbd@nbd.name> writes:
>> 
>> > On 2021-01-06 11:51, Toke Høiland-Jørgensen wrote:
>> >> Ryder Lee <ryder.lee@mediatek.com> writes:
>> >> 
>> >>> The selected txq should be scheduled unconditionally if
>> >>> NL80211_EXT_FEATURE_AIRTIME_FAIRNESS is not set by driver.
>> >>>
>> >>> Also put the sta to the end of the active_txqs list if
>> >>> deficit is negative then move on to the next txq.
>> >> 
>> >> Why is this needed? If the feature is not set, no airtime should ever be
>> >> accounted to the station, and so sta->airtime[txqi->txq.ac].deficit will
>> >> always be 0 - so you're just adding another check that doesn't actually
>> >> change the behaviour, aren't you?
>> >
>> > I think it might make sense to keep airtime reporting even when airtime
>> > fairness is disabled at run time, so this patch makes sense to me.
>> > Instead of this patch, the right place to deal with this would probably
>> > be ieee80211_sta_register_airtime.
>> 
>> When the fairness mechanism is user-disabled I agree it makes sense to
>> still keep the accounting; and in fact that's what
>> ieee80211_sta_register_airtime() already does when the accounting is
>> turned off by way of the airtime_flags field... So don't think anything
>> else is needed there either?
>> 
>> -Toke
>
> Not sure I get this right. Are you talking about local->airtime_flags =
> AIRTIME_USE_TX | AIRTIME_USE_RX ? I think that's different and we still
> need to take NL80211_EXT_FEATURE_AIRTIME_FAIRNESS into account, right?

I just meant that what Felix was asking for (a way *for the user* to
disable airtime fairness while still getting the airtime usage
accounted) is possible by setting those flags. The EXT_FEATURE flag is
meant as a way for the driver to signal to mac80211 that it supports
reporting airtime at all; so ideally it should be a flag that is only
set once.

Going back and reading your initial response it seems like you may be
toggling the flag dynamically in the driver, though? Is this accurate?
And if so, why? Is it not enough for you to fiddle with the
USE_TX/USE_RX flags? :)

-Toke

  reply	other threads:[~2021-01-07 13:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-06  1:01 [PATCH] mac80211: check ATF flag in ieee80211_next_txq() Ryder Lee
2021-01-06  1:01 ` Ryder Lee
2021-01-06 10:51 ` Toke Høiland-Jørgensen
2021-01-06 10:51   ` Toke Høiland-Jørgensen
2021-01-06 11:50   ` Ryder Lee
2021-01-06 11:50     ` Ryder Lee
2021-01-06 13:30   ` Felix Fietkau
2021-01-06 13:30     ` Felix Fietkau
2021-01-06 15:41     ` Toke Høiland-Jørgensen
2021-01-06 15:41       ` Toke Høiland-Jørgensen
2021-01-07  2:11       ` Ryder Lee
2021-01-07  2:11         ` Ryder Lee
2021-01-07 13:08         ` Toke Høiland-Jørgensen [this message]
2021-01-07 13:08           ` Toke Høiland-Jørgensen
2021-01-08  2:25           ` Ryder Lee
2021-01-08  2:25             ` Ryder Lee

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=87a6tkki7m.fsf@toke.dk \
    --to=toke@toke.dk \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=lorenzo.bianconi@redhat.com \
    --cc=nbd@nbd.name \
    --cc=ryder.lee@mediatek.com \
    --cc=shayne.chen@mediatek.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.