Thread (30 messages) 30 messages, 3 authors, 2018-08-29

Re: [RFC v2 2/4] mac80211: Add airtime accounting and scheduling to TXQs

From: Johannes Berg <johannes@sipsolutions.net>
Date: 2018-08-29 14:36:27

On Wed, 2018-08-29 at 12:33 +0200, Toke Høiland-Jørgensen wrote:
quoted
quoted
Hmm, the problem with a higher weight is that weight*quantum becomes the
time each station is scheduled, so having a higher value means higher
latency. This could be fixed by replacing the station weights with
per-station quantums, but I felt that this was exposing an
implementation detail in the API; if we ever change the enforcement
mechanism to not be quantum-based (as may be necessary for MU-MIMO for
instance), we'll have to convert values in the kernel. Whereas weights
are a conceptual measure that is not tied to any particular
implementation.
Ok, but that's also an effect you should describe in the API for it.
What's the right place to put that? In the netlink header file?
Right.
quoted
Perhaps then it should just be fractional? i.e. 8.8 bits or so?, so
the default would be 1.0 (0x0100) and then you could scale down to 0.5
(0x0080) etc?
Hmm, that's an interesting idea. I'll have to run some numbers to see
how the precision holds up on various examples; but that would allow us
to get rid of the quantum in the userspace API entirely, which is a good
thing as far as I'm concerned!
:-)

We can always go to 32 bits and then we have lots to play with? It's 16
bits right now so I picked 8.8 for no real reason - in fact that seems
quite pointless since dividing 300us by 256 gives you only just over 1us
which is really short.

So perhaps 12.4 (minimum 18 usec) is more appropriate?

But perhaps I'm just completely mistaken and you don't really want to be
able to scale the quantum down further at all, and so you have to play
with all the stations anyway?

No idea, really, how you'd use this.
quoted
quoted
For the drivers that get airtime as part of TX completion, sure; but as
I understand it, at least ath10k gets airtime information in out of band
status reports, so there would need to be a callback for that in any
case...
Hmm, ok, but perhaps then we should also tie those to the existing
airtime things?
Eh? Tie what to which existing airtime things?
At least WMM-AC: ieee80211_sta_tx_wmm_ac_notify().

johannes
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help