Brian Norris <briannorris@xxxxxxxxxxxx> writes: > > On Tue, Mar 24, 2020 at 7:55 PM Tony Chuang <yhchuang@xxxxxxxxxxx> > wrote: > > Brian Norris <briannorris@xxxxxxxxxxxx> writes: > > We want to measure the TX power, and the equipment just cannot > > detect the signal on some rates, unless we "fix" the rate exactly. > > I think we all understand this now. > > > So NL80211_CMD_SET_TX_BITRATE_MASK is not so useful for us > > sometimes. > > I'm not sure if you have directly explained why this is the case. See > your comment earlier: > > "This command just mask out some of rates that are not allowed." > > Sure, but if you mask out all but 1 bitrate...voila! A fixed rate! > > And this: > > "But actually the firmware has its own rate > adaptive mechanism, so mask out the other rates does not mean the rate > left will be chosen." > > 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. 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*? 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? 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. > > Now, there are other problems, like the others that Ben mentioned: the > rest of the mac80211 framework doesn't like it too much if you really > disable all but 1 rate (arguably a mac80211 bug -- but not a nl80211 > bug); or maybe you want to differentiate management frames and data > frames (and that's not what the current > NL80211_CMD_SET_TX_BITRATE_MASK allows for). > > I'm still not (personally) expecting that you *must* do this all via > the existing CMD_SET_TX_BITRATE_MASK, but to satisfy everyone involved > here, you at least need to be clear about why you aren't. > Yen-Hsuan
