From owner-freebsd-wireless@FreeBSD.ORG Wed Apr 18 09:46:07 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 835B01065673 for ; Wed, 18 Apr 2012 09:46:07 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id EB5748FC19 for ; Wed, 18 Apr 2012 09:46:06 +0000 (UTC) Received: by lagv3 with SMTP id v3so6965224lag.13 for ; Wed, 18 Apr 2012 02:46:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=HtCqOjvvidQPQgoxJh2aog3GbpRBMO6z7nZ5HdRD7QE=; b=YGdv//qfrbM3WmdfiFWKYqC+NXaa2/mlSEdWd0lT06VXIboG0YSKKMnzgc+5ss9Tci 2P+GCF7cEGBiI5+XDzl5C6IyzZPLF+371zuFx/IZp82sq/Gd2rG6HJgjAiJI5EB/cZ2g gbB/8KX7mT8O3cnPK9qymun2F+ANXisJh0LYIlb21fEn5TYcV3N3rqkTbmJ9Q5P1Vnb9 //EYXOJOkFZg3wSmlTP19mg0V4mbB3nGGj4ffur2vsBxnZ68G+MKmZuj4VDr3oVGiAjv WyJ3K01vYLmT9HZhnMmwJA7n4RqbZyQ88o/IhL7bLJtRBOr2e8Eb7amwhXPMi0RnYt1V ui2w== MIME-Version: 1.0 Received: by 10.152.112.100 with SMTP id ip4mr1520830lab.1.1334742365736; Wed, 18 Apr 2012 02:46:05 -0700 (PDT) Sender: bschmidt@techwires.net Received: by 10.152.144.195 with HTTP; Wed, 18 Apr 2012 02:46:05 -0700 (PDT) X-Originating-IP: [79.140.39.245] In-Reply-To: References: Date: Wed, 18 Apr 2012 11:46:05 +0200 X-Google-Sender-Auth: U9dbEdZ7ppUY4j7HlvcYbhJu_xI Message-ID: From: Bernhard Schmidt To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkH5XirnZG2wHA5WzsFWVVA7FwzHTQDgNxGK9i9He5gkypyjlYCRa9scohLgQyMShmIfZx6 Cc: Subject: Re: Question: IEEE80211_RATE_BASIC versus IEEE80211_RATE_MCS ? X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 09:46:07 -0000 On Wed, Apr 18, 2012 at 11:36, Bernhard Schmidt wrot= e: > On Tue, Apr 17, 2012 at 20:12, Adrian Chadd 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