On Wed, 2020-03-18 at 09:02 +0000, Tony Chuang wrote: > > This command just mask out some of rates that are not allowed. But the > firmware has its own rate adaptive mechanism to choose the rates. So mask > out all of the other rate doesn't make sure the packets will be transmitted by > the only rate that was not masked. The hardware/firmware will try to choose > a better rate (ex. 1Mbps or 6Mbps) if they think it's necessary. Also the device > will fallback the rates to try to find a better rate to transfer data to the peer. [...] > We probably have to modify the command parser, from user-space and the > nl80211 domain, because as far I don't see a good way to add fix rate > option on the NL80211_CMD_SET_TX_BITRATE_MASK without changing > the existing mechanism. If the mechanism is changed, then the "old" drivers > will fail to interpret the nl80211 attributes. So I think add a new one, which > can fix the TX rate, disable the rate adaptive, etc., will be better if necessary. IMHO we should consider the use case here. _Why_ do you need something like this? Brian can probably comment on this - I think ChromeOS (used to) use(s) some kind of fixed rate at the beginning of the connection to force low rates? But I also remember this interacting badly with some APs that just don't want to enable low rates at all... I think we also have a similar debugfs entry in iwlwifi which literally forces a single rate/configuration (including antenna) for the device to use, to test certain things. I'm not convinced that it'd be easy and would make a lot of sense to add support for all these kinds of knobs to nl80211 since they're really just used in limited testing scenarios. So IMHO the "can this be put into nl80211" isn't necessarily the most important thing - we don't *have* to clutter that with various knobs that are only supported by some drivers, and then only used for testing ... johannes
