All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ryder Lee <ryder.lee@mediatek.com>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
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, 7 Jan 2021 10:11:01 +0800	[thread overview]
Message-ID: <1609985461.9743.2.camel@mtkswgap22> (raw)
In-Reply-To: <87k0sq3wfl.fsf@toke.dk>

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?

Ryder

_______________________________________________
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: Ryder Lee <ryder.lee@mediatek.com>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
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, 7 Jan 2021 10:11:01 +0800	[thread overview]
Message-ID: <1609985461.9743.2.camel@mtkswgap22> (raw)
In-Reply-To: <87k0sq3wfl.fsf@toke.dk>

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?

Ryder


  reply	other threads:[~2021-01-07  2:21 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 [this message]
2021-01-07  2:11         ` Ryder Lee
2021-01-07 13:08         ` Toke Høiland-Jørgensen
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=1609985461.9743.2.camel@mtkswgap22 \
    --to=ryder.lee@mediatek.com \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=lorenzo.bianconi@redhat.com \
    --cc=nbd@nbd.name \
    --cc=shayne.chen@mediatek.com \
    --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 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.