On Wed, 2020-03-25 at 05:54 +0000, Tony Chuang wrote: > > That's entirely your fault, not the fault of the API. If your firmware > > doesn't listen to your driver, then that's either your firmware or > > your driver's fault. If you set a mask that has exactly 1 bitrate in > > it... well, that's exactly what you should tell your firmware to do. > > Not, "use this 1 bitrate, but try something else if you feel like it." > > I cannot agree with it. I tend to agree with Brian. If userspace, for some reason, told you that only one rate is acceptable, then you should listen to that - if you support the API at all. > Let's be clear here: > > If there's a rate mask comes from upper space, does it mean > That driver or firmware/hardware can only use those rates > masked when *802.11 retry*? Yes. > And use a lower rate when > retry is called rate-fallback as I've mentioned before. So I > think the problem here is, do we need another option in the > existing nl80211 command, if 802.11 *retry* is still allowed to > choose a rate not in the rate mask? Perhaps you'd like to have such an extension to the API, but that's not what's there today. Today, the expectation is that you use these rates, not some other rates you figured out from something. Now, mac80211 is/was actually slightly buggy here at some point, and not all drivers support this, but that's what the API was intended for. Not some kind of "oh, let's try to start with these rates and then do whatever we like later". > In my opinion, if 802.11 > retry should be disabled, then all of the algorithm of the existing > rate adaptive mechanism for rtw88 should be totally re-designed > and we will have to rebuild another one. Disabling retries has nothing to do with it. Only limiting the rates that can be used (even for retries). johannes
