Johannes Berg [off-list ref] writes:

On Wed, 2018-08-29 at 11:27 +0200, Toke H=C3=B8iland-J=C3=B8rgensen wrote:

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?

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!

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?

-Toke