David Young wrote:
> On Thu, Feb 15, 2007 at 05:08:21PM -0800, Sam Leffler wrote:
>> The way if_media is currently used for 802.11 does not scale well and
>> adding 11n support isn't even possible because there aren't enough free
>> bits in places.  Does anything have any feelings about this stuff?  I
>> think that splitting the tx rate out will make things work.  Not sure
>> how to deal with backwards compatibility.
> 
> I believe we must leave the existing NetBSD media words as-is, but that
> is probably not too onerous.  I am A-OK with leaving 802.11n rates out
> of the media word.

Well there's no room for the 11n rates and the combinatorial explosion
from adding any would be painful (it's already quite bad).  More
important is the question of how people use this stuff.  It's already
getting pretty painful to specify things on the command line to ifconfig
and only going to get worse with all the potential media configuration
for 11n.

Leaving the existing rates is fine but I suggest specifying their use
via if_media needs to be deprecated.  Instead there should be a new
mechanism (i.e. ioctl) used to set a fixed transmit rate and/or another
to constrain the basic rate set.  There are also semi-shorthand notions
in this area like "pureg" for constraining a BSS to 11g-only stations
(but not ofdm-only).  For most people the netband mechanism is really
just a shorthand for constraining the set of channels to scan looking
for an ap and/or for selecting a channel to setup operation on.

I'm mostly trying to get a consensus on what the right approach is.  I
am actively doing 11n work and would like to see consistency between
*bsd (mostly netbsd, freebsd, and dflybsd these days).

> 
> I have been working w/ 802.11n for a client for the past several months,
> so I have a lot of ideas.  Here is a strawman proposal for 802.11n
> media settings:
> 
> Let's add some new 802.11 modes.  Today we have 7 bits to store the
> 802.11 mode.  Here are today's modes:
> 
> #define IFM_IEEE80211_11A       0x00010000      /* 5 GHz, OFDM mode */
> #define IFM_IEEE80211_11B       0x00020000      /* Direct Sequence mode */
> #define IFM_IEEE80211_11G       0x00030000      /* 2 GHz, CCK mode */
> #define IFM_IEEE80211_FH        0x00040000      /* 2 GHz, GFSK mode */
> 
> Let's add/rename 802.11 modes like so.  (I am sneakily adding a new
> "legacy" mode for "pure G" stations, and giving an old mode a more
> suitable name.)
> 
> #define IFM_IEEE80211_11A       0x00010000      /* 5 GHz, OFDM mode */
> #define IFM_IEEE80211_11B       0x00020000      /* Direct Sequence mode */
> #define IFM_IEEE80211_11BG      0x00030000      /* 2 GHz, CCK/OFDM */
> #define IFM_IEEE80211_FH        0x00040000      /* 2 GHz, GFSK mode */
> #define IFM_IEEE80211_11G       0x00050000      /* 2 GHz, OFDM only */
> #define IFM_IEEE80211_11AGN     0x00060000      /* HT plus legacy OFDM */
> #define IFM_IEEE80211_11ABGN    0x00070000      /* HT plus legacy CCK/OFDM */

FWIW my defs are IFM_IEEE80211_11NA and IFM_IEEE80211_11NG.  I prefer
not to make changes to existing names (at least not w/o compat shims).
I am not sure adding an ofdm-only mode bit is worthwhile given how close
we are to using all available bits.  I am aware of only 1 card that
needs this; Atheros 5211 was "pureg only".  Can you think of something
else to justify adding it?

> 
> Let's let the determined operator "fix" a legacy rate in all modes above.

Fixing a legacy rate in an HT-capable operating mode makes no sense to
me and is likely to cause confusion.  But we need to continue supporting
the notation for legacy (i.e. non-HT) modes.

> 
> Let's add a media word for "pure" N mode.  At a glance, 0x00080000 is
> unused, so I use that.  I don't see any use in letting apps set an HT
> rate using the media word.  We will provide for that a little later.
> 
> #define IFM_IEEE80211_11N       0x00080000      /* Pure N mode */

This is really IFM_IEEE80211_HT.

> 
> We are not quite finished.  For 802.11n, we need to specify some
> additional media parameters, such as MCS ID, short/long guard interval,
> channel width, and upper/lower channel extension.  I believe short/long
> guard interval and eligible MCS IDs belong in one ioctl:
> 
>         #define IEEE80211_IOC_HT        TBD
> 
>         struct ieee80211_ht_req {
>                 char                            i_name[IFNAMSIZ];
>                 uint16_t                        i_type;
>                 struct ieee80211_ht_params      *i_param;
>         };
> 
>         struct ieee80211_ht_params {
>                 uint32_t        p_flags;
> #define IEEE80211_HTFLAG_GI_MASK        __BITS(1,0)     /* GI mode */
> #define IEEE80211_HTFLAG_GI_AUTO        __SHIFTIN(0, IEEE80211_HTFLAG_GI_MASK)
> #define IEEE80211_HTFLAG_GI_SHORT       __SHIFTIN(1, IEEE80211_HTFLAG_GI_MASK)
> #define IEEE80211_HTFLAG_GI_LONG        __SHIFTIN(2, IEEE80211_HTFLAG_GI_MASK)
> #define IEEE80211_HTFLAG_40             __BIT(2)/* ok to auto-select a 40 MHz
>                                                  * channel
>                                                  */
>                 uint8_t         p_mcsset[16];   /* bitmap of eligible MCS IDs */
>         };

There are many more things than this but I'm not looking to define the
ancillary ioctls; just resolve how the media definitions are handled.

> 
> To set the channel width and extension channel, let's use the upper bits
> of the 16-bit channel word we pass to SIOCS80211CHANNEL[1]:
> 
> #define IEEE80211_CHAN_40MHZ_UPEXT      0x8000
> #define IEEE80211_CHAN_40MHZ_LOEXT      0xC000
> 
> I have no doubt left media parameters out, made a bunch of typos, etc.
> 
> Dave
> 
> [1] FWIW, I have used and still like the ifconfig notation 'ch+' and
>     'ch-' for upper/lower channel extension.
> 
>         ifconfig w0 chan 11-
>         ifconfig w0 chan 1+
> 

Channel numbers are increasingly meaningless.  I've switched almost
entirely to using frequency + notation that specifies channel-specific
operation characteristics like CWM.  User space programs read the
channel table from the kernel and use that to do mapping.  This insures
there is consistency in any mapping between frequency and IEEE channel
numbers (critical for sta interoperation for things like the Public
Safety Band).

So it sounds like you're in agreement that we should move some of the
operational parameters that were previously done using if_media into
separate mechanisms.  That's really what I was looking for.

	Sam