Mode/Channel/Bitrate API

Mode/Channel/Bitrate API

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 2343 bytes --]

Hey,

So many people seem to agree that the capability registering in mac80211
is somewhat awkward to use. Also, it doesn't really match how hardware
works with the separation of B and G mode.

I've been thinking about this for a while and would like to get your
input on the following replacement API.

First, I think we should completely get rid of the mode stuff. This is
an artificial distinction between hardware supports operating in
frequency bands, not in modes, and the actual mode differences are
controlled differently.

Hence, what I'm thinking is that

 (a) the driver registers which channel center frequencies it can
     operate with, it could in theory just be a range (e.g. 2400-2500
     MHz) or more practically be list of center frequencies. Just
     contains frequencies and possibly hardware dependent values for the
     frequency. This is done in "bands", something like
     FREQUENCY_BAND_2_4GHZ and FREQUENCY_BAND_5GHZ, "bands" replace the
     current "modes".
 (b) additionally, the driver registers as flags
     - whether it can support G mode short slot operation
     - whether it can receive B mode short barker preambles
     (both of which are only relevant if it supports 2.4 GHz operation)
 (c) for each registered band, the driver registers which bitrates the
     hw supports. this implicitly defines the modulation too.
 (d) now, selecting a channel by frequency is unique, but we need to
     give new options to select short slot, short preamble and allowed
     bitrates. For client mode, these are initialised to what the AP
     supports and you can't for example turn off short slot when the AP
     requires it; for AP mode it's initialised to what the HW supports
     but if you want less you can select that. Rate control algorithms
     need to take into account this as well similar to what they already
     do.

Does anyone see problems with this? I think it matches hardware much
better than the current scheme where B and G mode almost totally
overlap. Also, right now we only advertise short preamble for when we
have G mode support which is wrong since short preamble was an optional
feature of 11B, currently 11B hardware that supports short preambles
will never be able to associate to an AP that requires it with mac80211.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Mode/Channel/Bitrate API

[Michael Wu]

[-- Attachment #1: Type: text/plain, Size: 1402 bytes --]

On Friday 12 October 2007 16:48:30 Johannes Berg wrote:
>  (a) the driver registers which channel center frequencies it can
>      operate with, it could in theory just be a range (e.g. 2400-2500
>      MHz) or more practically be list of center frequencies. 
List would be best, but..

>      Just 
>      contains frequencies and possibly hardware dependent values for the
>      frequency. This is done in "bands", something like
>      FREQUENCY_BAND_2_4GHZ and FREQUENCY_BAND_5GHZ, "bands" replace the
>      current "modes".
Being able to just register frequency bands would work for many (but not all) 
drivers out there and would be more convenient than listing everything.

>  (b) additionally, the driver registers as flags
>      - whether it can support G mode short slot operation
>      - whether it can receive B mode short barker preambles
>      (both of which are only relevant if it supports 2.4 GHz operation)
I haven't seen any softmac 11b hardware that doesn't support receiving short 
preamble yet.

>  (d) now, selecting a channel by frequency is unique, but we need to
>      give new options to select short slot, short preamble and allowed
>      bitrates.
Short preamble? What would the hardware do with this bit?

> Does anyone see problems with this?
More specific examples of the API you have in mind would be helpful.

Thanks,
-Michael Wu

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: Mode/Channel/Bitrate API

[Tomas Winkler]

On 10/16/07, Michael Wu <flamingice@sourmilk.net> wrote:
> On Friday 12 October 2007 16:48:30 Johannes Berg wrote:
> >  (a) the driver registers which channel center frequencies it can
> >      operate with, it could in theory just be a range (e.g. 2400-2500
> >      MHz) or more practically be list of center frequencies.
> List would be best, but..
>
> >      Just
> >      contains frequencies and possibly hardware dependent values for the
> >      frequency. This is done in "bands", something like
> >      FREQUENCY_BAND_2_4GHZ and FREQUENCY_BAND_5GHZ, "bands" replace the
> >      current "modes".
> Being able to just register frequency bands would work for many (but not all)
> drivers out there and would be more convenient than listing everything.
>
> >  (b) additionally, the driver registers as flags
> >      - whether it can support G mode short slot operation
> >      - whether it can receive B mode short barker preambles
> >      (both of which are only relevant if it supports 2.4 GHz operation)
> I haven't seen any softmac 11b hardware that doesn't support receiving short
> preamble yet.
>
There are old AP  can be configured to use long preamble, so it shell
be configurable also in station.

> >  (d) now, selecting a channel by frequency is unique, but we need to
> >      give new options to select short slot, short preamble and allowed
> >      bitrates.
> Short preamble? What would the hardware do with this bit?
>
Will use short preamble ? In B/G it should use long preamble if not
configured otherwise.

> > Does anyone see problems with this?
> More specific examples of the API you have in mind would be helpful.
>
> Thanks,
> -Michael Wu
>
>

Re: Mode/Channel/Bitrate API

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 2058 bytes --]

On Tue, 2007-10-16 at 16:40 -0400, Michael Wu wrote:
> On Friday 12 October 2007 16:48:30 Johannes Berg wrote:
> >  (a) the driver registers which channel center frequencies it can
> >      operate with, it could in theory just be a range (e.g. 2400-2500
> >      MHz) or more practically be list of center frequencies. 
> List would be best, but..
> 
> >      Just 
> >      contains frequencies and possibly hardware dependent values for the
> >      frequency. This is done in "bands", something like
> >      FREQUENCY_BAND_2_4GHZ and FREQUENCY_BAND_5GHZ, "bands" replace the
> >      current "modes".
> Being able to just register frequency bands would work for many (but not all) 
> drivers out there and would be more convenient than listing everything.

Yeah but it doesn't help when the user wants to enable/disable certain
channels or the regulatory code needs to, so it seems we need to go with
a list.

> >  (b) additionally, the driver registers as flags
> >      - whether it can support G mode short slot operation
> >      - whether it can receive B mode short barker preambles
> >      (both of which are only relevant if it supports 2.4 GHz operation)
> I haven't seen any softmac 11b hardware that doesn't support receiving short 
> preamble yet.

Ok, I guess we can add that whenever we have a 2.4GHz channel.

> >  (d) now, selecting a channel by frequency is unique, but we need to
> >      give new options to select short slot, short preamble and allowed
> >      bitrates.
> Short preamble? What would the hardware do with this bit?

Why hardware? For one, we need to advertise whether we support short
preamble or not in our association frame. So we need to know whether the
hardware supports it or not (which, together with OFDM support, is
basically 802.11g iirc).

> > Does anyone see problems with this?
> More specific examples of the API you have in mind would be helpful.

Don't really have any API in mind yet except for what I posted a long
time ago in Luis's thread.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Mode/Channel/Bitrate API

[Luis R. Rodriguez]

On 10/17/07, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2007-10-16 at 16:40 -0400, Michael Wu wrote:
> > On Friday 12 October 2007 16:48:30 Johannes Berg wrote:
> > >  (a) the driver registers which channel center frequencies it can
> > >      operate with, it could in theory just be a range (e.g. 2400-2500
> > >      MHz) or more practically be list of center frequencies.
> > List would be best, but..
> >
> > >      Just
> > >      contains frequencies and possibly hardware dependent values for the
> > >      frequency. This is done in "bands", something like
> > >      FREQUENCY_BAND_2_4GHZ and FREQUENCY_BAND_5GHZ, "bands" replace the
> > >      current "modes".
> > Being able to just register frequency bands would work for many (but not all)
> > drivers out there and would be more convenient than listing everything.
>
> Yeah but it doesn't help when the user wants to enable/disable certain
> channels or the regulatory code needs to, so it seems we need to go with
> a list.

The regulatory work can just iterate over the currently established
channels for each wiphy. Who defines those or how is not important to
the regulatory work. I'm not sure why the range approach would not
work here. A card usually works on a range of frequencies anyway.

  Luis

Re: Mode/Channel/Bitrate API

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1885 bytes --]

On Wed, 2007-10-17 at 10:15 -0400, Luis R. Rodriguez wrote:
> On 10/17/07, Johannes Berg <johannes@sipsolutions.net> wrote:
> > On Tue, 2007-10-16 at 16:40 -0400, Michael Wu wrote:
> > > On Friday 12 October 2007 16:48:30 Johannes Berg wrote:
> > > >  (a) the driver registers which channel center frequencies it can
> > > >      operate with, it could in theory just be a range (e.g. 2400-2500
> > > >      MHz) or more practically be list of center frequencies.
> > > List would be best, but..
> > >
> > > >      Just
> > > >      contains frequencies and possibly hardware dependent values for the
> > > >      frequency. This is done in "bands", something like
> > > >      FREQUENCY_BAND_2_4GHZ and FREQUENCY_BAND_5GHZ, "bands" replace the
> > > >      current "modes".
> > > Being able to just register frequency bands would work for many (but not all)
> > > drivers out there and would be more convenient than listing everything.
> >
> > Yeah but it doesn't help when the user wants to enable/disable certain
> > channels or the regulatory code needs to, so it seems we need to go with
> > a list.
> 
> The regulatory work can just iterate over the currently established
> channels for each wiphy. Who defines those or how is not important to
> the regulatory work. I'm not sure why the range approach would not
> work here. A card usually works on a range of frequencies anyway.

Right. But the regulatory code may need to have power restrictions
different on different channels and generally wants to be able to
restrict things for each channel, so it'd be good to have the list
defined right away by the driver. It seems that if we don't put this
into the driver but rather have a frequency range there, we need to
allocate an array of channels later for this work and that's not needed
if we start out with an array of channels.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Mode/Channel/Bitrate API

[Luis R. Rodriguez]

On 10/18/07, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Wed, 2007-10-17 at 10:15 -0400, Luis R. Rodriguez wrote:

> > The regulatory work can just iterate over the currently established
> > channels for each wiphy. Who defines those or how is not important to
> > the regulatory work. I'm not sure why the range approach would not
> > work here. A card usually works on a range of frequencies anyway.
>
> Right. But the regulatory code may need to have power restrictions
> different on different channels and generally wants to be able to
> restrict things for each channel,

Right but this is independent of how the driver sets his things up.

> so it'd be good to have the list
> defined right away by the driver.

The real problem here, as you pointed out to me before, is each driver
needs its own hw values for channels so I suppose it make sense to let
the driver set this.

> It seems that if we don't put this
> into the driver but rather have a frequency range there, we need to
> allocate an array of channels later for this work and that's not needed
> if we start out with an array of channels.

Right, we can provide a helper for driver to allocate/create the
channel array structure but as I noted they need to set hw values
anyway... so blah.

  Luis