Question: IEEE80211_RATE_BASIC versus IEEE80211_RATE_MCS ?

[Bernhard Schmidt]

On Wed, Apr 18, 2012 at 11:36, Bernhard Schmidt <bschmidt at freebsd.org> wrote:
> On Tue, Apr 17, 2012 at 20:12, Adrian Chadd <adrian at freebsd.org> wrote:
>> Hi,
>>
>> So after doing some digging into the rate representation, I've
>> discovered that both IEEE80211_RATE_BASIC and IEEE80211_RATE_MCS are
>> represented as the high bit set (ie, 0x80.)
>>
>> My query is - how exactly should we be representing rates, and is
>> there a clear, consistent, non-overlapping use case for where each is
>> used?
>>
>> This shows up in setbasicrates(), where the 11na/11ng modes have the
>> OFDM/CCK (respectively) rates set as basic, just like for 11a/11bg,
>> however the high bit is set. ifconfig(8) at least just looks at the tx
>> rateset list (which setbasicrates is setting up for us) and
>> mis-interpreting the high bit as MCS, rather than as "basic".
>>
>> Any ideas/suggestions? I'd be tempted to create a 'ratecode_t' that is
>> a uint8_t struct, then finding/fixing all instances where ratecode is
>> being passed in as a uint8_t, but that may be slightly overkill.
>
> In some places the current channel can be abused to determine if it's
> a MCS or legacy rate, but this is really just an ugly hack. As you've
> already noted, the basic rate flag isn't handle correctly, neither in
> status output nor in IEs in the MCS case. Though, I'm not sure we
> *really* need (BASIC | MCS) right now anywhere, can you think of a
> place? Hmm, right, ni_txrate might be one of those places.

Hmm, nope, ni_txrate actually doesn't require both.

> Basically we have 2 arrays ni_rates and ni_htrates, the later
> implicitly has the MCS flag set, both can set the BASIC flag as
> required. The tricky part is just to figure out when and where to
> drop/set the flags as required when assigning from one of the arrays
> to another variable.
>
> I pondered changing "rate"  to an uint16_t once and move all flags to
> the new byte, which would also allow to merge both arrays, but feared
> the ABI/API breakage..

-- 
Bernhard