RFC: unified BSS configuration approach

RFC: unified BSS configuration approach

[Ron Rindjunsky]

Hi everyone

few weeks ago Johannes published a patch based on my RFC "mac80211:
add unified BSS configuration", introducing a new op from mac80211 to
low-level driver "bss_info_changed", that delivers BSS IE changes and
assoc status information.
What we had originally in mind was that this op should eventually
replace previous ops calls for erp (uses "erp_ie_changed") ,wmm (uses
"conf_tx") and ht (uses "conf_ht"), all of them doing the same -
inform low-level driver about configuration of the BSS, based on the
IE in beacon or in assoc response. This approach is reflected in the
comment inside mac80211.h:

* @bss_info_changed: Handler for configuration requests related to BSS
* parameters that may vary during BSS's lifespan, and may affect low
* level driver (e.g. assoc/disassoc status, erp parameters).
* This function should not be used if no BSS has been set, unless
* for association indication. The @changed parameter indicates which
* of the bss parameters has changed when a call is made. This callback
* has to be atomic.

Now, there are several issues that I want to address regarding current status:

A)  erp_ie_changed and conf_tx were used not only to inform about BSS
changes, but in init flows as well, in order to config low-level
driver for an initial configuration, for instance in
"ieee80211_reset_erp_info", that is called both in
"ieee80211_set_associated" (assoc flow), and in "ieee80211_open" (init
flow)
B) If we decide to skip this initial sync problems may occur, as
initial status of mac80211 and low-level driver may be different.
C) yet, there is no need to make changes from beacons when we are not
associated, as our association may influence the beacons.
D) also, configuration should not be applied to low-level driver while
scanning as well, even though beacons/probe responses are inspected.
E) support to user space configuration is needed, e.g. AP mode
(although here we may use the fact that AP mode is always in a kind of
"associated" mode)

So, your comments are needed to what is the preferred approach:

1 - change the original intention of bss_info_changed so mac80211 will
be able to set low-level driver in the "init" or "configure" flows as
well, not only as BSS is formed or changes
2 - maintain original intention, use "bss_info_changed" only when we
want to deliver BSS configuration when we get associate or during
association state,  and deliver all initial configuration info through
different ops

I am not stating any of my own pro/cons yet, as I would like to hear
your opinion first, but once we get to a decision we should stick to
it, so low-level drivers will not suffer in the future...
Thanks
Ron

Re: RFC: unified BSS configuration approach

[Johannes Berg]

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

Hi Ron,

> few weeks ago Johannes published a patch based on my RFC "mac80211:
> add unified BSS configuration", introducing a new op from mac80211 to
> low-level driver "bss_info_changed", that delivers BSS IE changes and
> assoc status information.

That was actually merged too.

> What we had originally in mind was that this op should eventually
> replace previous ops calls for erp (uses "erp_ie_changed") ,wmm (uses
> "conf_tx") and ht (uses "conf_ht"), all of them doing the same -

erp_ie_changed should be gone now too.

> * @bss_info_changed: Handler for configuration requests related to BSS
> * parameters that may vary during BSS's lifespan, and may affect low
> * level driver (e.g. assoc/disassoc status, erp parameters).
> * This function should not be used if no BSS has been set, unless
> * for association indication. The @changed parameter indicates which
> * of the bss parameters has changed when a call is made. This callback
> * has to be atomic.
> 
> Now, there are several issues that I want to address regarding current status:
> 
> A)  erp_ie_changed and conf_tx were used not only to inform about BSS
> changes, but in init flows as well, in order to config low-level
> driver for an initial configuration, for instance in
> "ieee80211_reset_erp_info", that is called both in
> "ieee80211_set_associated" (assoc flow), and in "ieee80211_open" (init
> flow)

Good point. When writing that, I missed that it was called from
ieee80211_reset_erp_info().

> B) If we decide to skip this initial sync problems may occur, as
> initial status of mac80211 and low-level driver may be different.

Hm, true, that could happen. Does it happen in practice though? I can't
see why a low level driver would decide that it should have short
preamble or CTS protection on by default. Maybe we should just document
initial state? Or we can keep the initial call and remove that "don't
call w/o BSS" restriction instead, which seems saner. We should then
probably rename reset_erp_info() to reset_bss_info() though.

> C) yet, there is no need to make changes from beacons when we are not
> associated, as our association may influence the beacons.

Huh, yes, do we do that though? I didn't think we did. Well, we do in
one way, we set our initial status to whatever we "predict" the settings
will be when we join the BSS, if that changes we follow all changes. Are
there any problems with that?

> D) also, configuration should not be applied to low-level driver while
> scanning as well, even though beacons/probe responses are inspected.

Hm, good point. But we don't really react to things in other BSSes so
does it really matter whether we're scanning or not while receiving a
beacon from our own BSS?

> E) support to user space configuration is needed, e.g. AP mode
> (although here we may use the fact that AP mode is always in a kind of
> "associated" mode)

Yup, so far it's required only in AP mode, is there anything that will
need this when not in AP mode?

> 1 - change the original intention of bss_info_changed so mac80211 will
> be able to set low-level driver in the "init" or "configure" flows as
> well, not only as BSS is formed or changes
> 2 - maintain original intention, use "bss_info_changed" only when we
> want to deliver BSS configuration when we get associate or during
> association state,  and deliver all initial configuration info through
> different ops

I prefer the first option since that's essentially just a small
documentation change and it makes sense. We just should make sure that
it's called only when the device is started (through ->start()).

johannes

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

Re: RFC: unified BSS configuration approach

[Tomas Winkler]

> > B) If we decide to skip this initial sync problems may occur, as
> > initial status of mac80211 and low-level driver may be different.
>
> Hm, true, that could happen. Does it happen in practice though? I can't
> see why a low level driver would decide that it should have short
> preamble or CTS protection on by default. Maybe we should just document
> initial state? Or we can keep the initial call and remove that "don't
> call w/o BSS" restriction instead, which seems saner. We should then
> probably rename reset_erp_info() to reset_bss_info() though.

Yes it happens in practices. I think with short slot.
reset_bss_info() sounds good.

> > C) yet, there is no need to make changes from beacons when we are not
> > associated, as our association may influence the beacons.
>
> Huh, yes, do we do that though? I didn't think we did. Well, we do in
> one way, we set our initial status to whatever we "predict" the settings
> will be when we join the BSS, if that changes we follow all changes. Are
> there any problems with that?
>

We better don't predict, you get beacon or probe response and initiate
association with what is there.

Whit assoc==true all the parameters should be sent to driver at once.

> > D) also, configuration should not be applied to low-level driver while
> > scanning as well, even though beacons/probe responses are inspected.
>
> Hm, good point. But we don't really react to things in other BSSes so
> does it really matter whether we're scanning or not while receiving a
> beacon from our own BSS?
>

Either mac80211 or driver have to be aware that there is scanning and
not changing parameters. during that stage. I will get your own BSS
beacons with the relevant information after scanning so no caching is
needed. Need to be careful though about 11h quite period and channel
switch.

> > E) support to user space configuration is needed, e.g. AP mode
> > (although here we may use the fact that AP mode is always in a kind of
> > "associated" mode)
>
> Yup, so far it's required only in AP mode, is there anything that will
> need this when not in AP mode?

Preamble is usually user configurable feature..

> > 1 - change the original intention of bss_info_changed so mac80211 will
> > be able to set low-level driver in the "init" or "configure" flows as
> > well, not only as BSS is formed or changes
> > 2 - maintain original intention, use "bss_info_changed" only when we
> > want to deliver BSS configuration when we get associate or during
> > association state,  and deliver all initial configuration info through
> > different ops
>
> I prefer the first option since that's essentially just a small
> documentation change and it makes sense. We just should make sure that
> it's called only when the device is started (through ->start()).

what about reset_bss_info() ?

Thanks
Tomas

> johannes
>

Re: RFC: unified BSS configuration approach

[Johannes Berg]

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


> > Hm, true, that could happen. Does it happen in practice though? I can't
> > see why a low level driver would decide that it should have short
> > preamble or CTS protection on by default. Maybe we should just document
> > initial state? Or we can keep the initial call and remove that "don't
> > call w/o BSS" restriction instead, which seems saner. We should then
> > probably rename reset_erp_info() to reset_bss_info() though.
> 
> Yes it happens in practices. I think with short slot.
> reset_bss_info() sounds good.

Ok so let's rename reset_erp_info() to reset_bss_info() and have it
handle all the other stuff too.

> > > 1 - change the original intention of bss_info_changed so mac80211 will
> > > be able to set low-level driver in the "init" or "configure" flows as
> > > well, not only as BSS is formed or changes
> > > 2 - maintain original intention, use "bss_info_changed" only when we
> > > want to deliver BSS configuration when we get associate or during
> > > association state,  and deliver all initial configuration info through
> > > different ops
> >
> > I prefer the first option since that's essentially just a small
> > documentation change and it makes sense. We just should make sure that
> > it's called only when the device is started (through ->start()).
> 
> what about reset_bss_info() ?

Well reset_bss_info() would still call ->bss_info_changed(), no?

johannes

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

Re: RFC: unified BSS configuration approach

[Tomas Winkler]

On Jan 30, 2008 2:38 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
>
> > > Hm, true, that could happen. Does it happen in practice though? I can't
> > > see why a low level driver would decide that it should have short
> > > preamble or CTS protection on by default. Maybe we should just document
> > > initial state? Or we can keep the initial call and remove that "don't
> > > call w/o BSS" restriction instead, which seems saner. We should then
> > > probably rename reset_erp_info() to reset_bss_info() though.
> >
> > Yes it happens in practices. I think with short slot.
> > reset_bss_info() sounds good.
>
> Ok so let's rename reset_erp_info() to reset_bss_info() and have it
> handle all the other stuff too.
>
> > > > 1 - change the original intention of bss_info_changed so mac80211 will
> > > > be able to set low-level driver in the "init" or "configure" flows as
> > > > well, not only as BSS is formed or changes
> > > > 2 - maintain original intention, use "bss_info_changed" only when we
> > > > want to deliver BSS configuration when we get associate or during
> > > > association state,  and deliver all initial configuration info through
> > > > different ops
> > >
> > > I prefer the first option since that's essentially just a small
> > > documentation change and it makes sense. We just should make sure that
> > > it's called only when the device is started (through ->start()).
> >
> > what about reset_bss_info() ?
>
> Well reset_bss_info() would still call ->bss_info_changed(), no?

Sounds good so far.

> johannes
>