Johannes Berg <johannes@xxxxxxxxxxxxxxxx> writes: > On Wed, 2018-08-29 at 11:27 +0200, Toke Høiland-Jørgensen wrote: > >> 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! >> 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
