Date: Thu, 4 Jul 2013 17:54:57 -0700 From: Adrian Chadd <adrian@freebsd.org> To: freebsd-wireless@freebsd.org Subject: Re: [cft] net80211 PHY changes to include 11n tables, take #1 Message-ID: <CAJ-Vmo=_Z8aPurRtXTy55PYpR8LEauAwVmdtc%2B81e_H2Pi=3Kg@mail.gmail.com> In-Reply-To: <CAJ-VmokKSe1xbE3GwRvxOyFcoZMbvdjWm2819smOMF5QtvSW4A@mail.gmail.com> References: <CAJ-VmokKSe1xbE3GwRvxOyFcoZMbvdjWm2819smOMF5QtvSW4A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is now in -HEAD. -adrian On 30 June 2013 20:13, Adrian Chadd <adrian@freebsd.org> wrote: > Hi all, > > As part of adding 11n awareness to various parts of net80211 (TDMA, > 802.11s code, implementing AMSDU, 11n+fast-frames support, TX rate > control) the PHY table code needs to be taught about said rates. > > Unfortunately the PHY code as it stands only knows about non-11n > stuff. To add to the pain, the basic rate bit (0x80) is the same as > the MCS rate bit (0x80). They're supposed to not be used in > overlapping contexts but in some places (notable ni->tx_rate, for > example!) they are. In this code, the rate code -> table index code > makes the unfortunate mistake of also indexing things with the basic > rate bit set, which messes up MCS rates. > > The "real" solution is to make the basic rate and mcs rate bits either > much higher bits, or to turn the rate representation into a struct > with the rate code / speed and PHY bits (eg, BASIC, MCS, etc). That's > a big change that touches a _lot_ of code so I'm not yet willing to go > and do all that work. It's likely I'm going to have to for 802.11ac > support however. Sniffle. > > The "real real" solution is to not use this rate table index thing > outside of a very specific set of instances. I can unfortunately see a > million little race conditions here where the driver holds onto a rate > table index whilst doing something, whilst some other part of the code > decides to wholesale change said rate table underneath it. it's > terrifying; I may end up having to do a further pass and kill this > whole "use the rate table index" thing outside of contexts that I can > protect things with locks. > > So, here's what I've done: > > * Make the current PHY and rate table lookup routines non-11n only. If > the BASIC bit is set (0x80) then it panics. > * Add the 11n rates into the PHY tables > * Add some accessor methods to do the ratecode->rateindex lookup > rather than manually going grubbing around in ieee80211com. > * Modify callers of the ratecode->rateindex routines to strip the > basic bit if it's set. They all assume it's legacy at this point, so > it's fine. > > I've tested this on ath (where it should be a no-op) and iwn (where it > does use the PHY table and rate control code.) So far, so good. I > haven't sat down and fully debugged whether populating the 11n rate > table with 11n rates is causing confusion in the iwn code - the iwn > code does some magic crap somewhere to "pretend" the rates are non-11n > when they indeed are, so the rate control code can do it's thing. i'd > obviously like to kill _that_. > > The patch is here: > > http://people.freebsd.org/~adrian/ath/20130630-net80211-phy-11n-1.diff > > Please give it a whirl. It's only really going to show up if your > device uses the net80211 rate control code. As it patches ral and iwn, > I'm doubly interested in those devices. > > I'd like to commit this in a couple of days and start working on > undoing the brain damage in iwn so the rate control modules can > actually do 11n rate table lookups. > > Thanks! > > > -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=_Z8aPurRtXTy55PYpR8LEauAwVmdtc%2B81e_H2Pi=3Kg>