Date: Wed, 18 Apr 2012 11:46:05 +0200 From: Bernhard Schmidt <bschmidt@freebsd.org> To: freebsd-wireless@freebsd.org Subject: Re: Question: IEEE80211_RATE_BASIC versus IEEE80211_RATE_MCS ? Message-ID: <CAAgh0_aYFGHNpuiHweYNd2qzfkydsfAHsPzEM2xWaOScoZTFcw@mail.gmail.com> In-Reply-To: <CAAgh0_agsfY66Se7ej8VhGhNeAcKUTJO8KMY8Frhq1qZvfem-Q@mail.gmail.com> References: <CAJ-Vmo=L8jhvBwoLpF1Hu1M870ZV%2Bp-G5Vn6HW-HCFV842KLBw@mail.gmail.com> <CAAgh0_agsfY66Se7ej8VhGhNeAcKUTJO8KMY8Frhq1qZvfem-Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 18, 2012 at 11:36, Bernhard Schmidt <bschmidt@freebsd.org> wrot= e: > On Tue, Apr 17, 2012 at 20:12, Adrian Chadd <adrian@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" =A0to 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.. --=20 Bernhard
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAAgh0_aYFGHNpuiHweYNd2qzfkydsfAHsPzEM2xWaOScoZTFcw>