From owner-freebsd-wireless@FreeBSD.ORG Mon Jul 1 03:19:32 2013 Return-Path: <owner-freebsd-wireless@FreeBSD.ORG> Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 562B3C9 for <freebsd-wireless@freebsd.org>; Mon, 1 Jul 2013 03:19:32 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 1F66619E3 for <freebsd-wireless@freebsd.org>; Mon, 1 Jul 2013 03:19:32 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id n1so2565387qcw.16 for <freebsd-wireless@freebsd.org>; Sun, 30 Jun 2013 20:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=AUsQ4ufJfUWenABc9VBljr3Ku82fYXpJT7JEAJ/Wsag=; b=gzWTGkEmV2U9+JdC2aDzsn1xo+NtqQVpMeAmOHQBzh48PgMH4S8wmVIE0xhBTBV2io 6pkld8SUH9KdMi9LoGwaAd4GS0uKxVUYPgNLuefBKnbJfhhIJ5x0hD7ZZjBijugz/xy4 9o2Cp2SWTvFJwyvvbuFRdHjqm4MPOJkyG9ro+aZyE4z17l6IrZMSYM6mAkcjcF8YcG5x i7H/mBxCQKZvvwht8zDJQcRGUnUU8k1GJ1pL1hAEWM5zvts2R+ng6l0g+7UHbac9WLLg POAag7Wi5Dem/mnC4MXFf7aw/WPbxez/7v7NFG+WoOwlAHKV4/bjuLC3nLOfvx+J98Bl OVLg== MIME-Version: 1.0 X-Received: by 10.229.136.7 with SMTP id p7mr7107649qct.48.1372648394309; Sun, 30 Jun 2013 20:13:14 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.101.134 with HTTP; Sun, 30 Jun 2013 20:13:14 -0700 (PDT) Date: Sun, 30 Jun 2013 20:13:14 -0700 X-Google-Sender-Auth: 1NtnhssfUrEx7up41MthJD0fWd0 Message-ID: <CAJ-VmokKSe1xbE3GwRvxOyFcoZMbvdjWm2819smOMF5QtvSW4A@mail.gmail.com> Subject: [cft] net80211 PHY changes to include 11n tables, take #1 From: Adrian Chadd <adrian@freebsd.org> To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." <freebsd-wireless.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-wireless>, <mailto:freebsd-wireless-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-wireless> List-Post: <mailto:freebsd-wireless@freebsd.org> List-Help: <mailto:freebsd-wireless-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-wireless>, <mailto:freebsd-wireless-request@freebsd.org?subject=subscribe> X-List-Received-Date: Mon, 01 Jul 2013 03:19:32 -0000 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