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