Johannes Berg <johannes@xxxxxxxxxxxxxxxx> writes: > On Mon, 2018-07-09 at 18:37 +0200, Toke Høiland-Jørgensen wrote: >> >> @@ -427,6 +428,8 @@ struct sta_info *sta_info_alloc(struct ieee80211_sub_if_data *sdata, >> sta->cparams.interval = MS2TIME(100); >> sta->cparams.ecn = true; >> >> + sta->airtime.weight = 1; > > Perhaps it might be useful to start with a higher default (even > something like 1<<8) as that would allow adjusting up/down single > stations, without having to adjust all stations and listening to new > additions to adjust them quickly etc? > > Theoretically this doesn't really matter, but from a practical POV it > may be easier to leave them all at the default and just adjust the ones > that need adjustment for some reason. 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. >> ieee80211_sta_register_airtime > > Do we really need this? We already have at least TX status with > airtime, for ieee80211_sta_tx_notify() and friends, and the station > pointer in that context, so couldn't we piggy-back on this? At least > WMM-AC already requires the driver to provide this. 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... -Toke
