Re: [PATCH/RFC] set_rates support for prism54

Re: [PATCH/RFC] set_rates support for prism54

[Margit Schubert-While]

I disagree with this.
We don't need parameter parsing either in the driver or in
wireless.c.
There is a perfectly good infrastructure in wireless tools iwpriv.c
Take a look at around line 375 in iwpriv.c for the
existing example of IW_PRIV_TYPE_FLOAT.
This could be adapted for this purpose (IW_PRIV_TYPE_BITRATE ?)
and (mis)use the iw_freq structure to pass the values and extra info.

This is probably the least invasive and can be tied to a particular WE
release.

Also we seem to have forgotten the 5 GHz band with 72, 100, 108
rates and only ofdm allowable.

Margit

Re: Re: [PATCH/RFC] set_rates support for prism54

[Denis Vlasenko]

On Sunday 15 August 2004 16:21, Margit Schubert-While wrote:
> I disagree with this.
> We don't need parameter parsing either in the driver or in
> wireless.c.
> There is a perfectly good infrastructure in wireless tools iwpriv.c
> Take a look at around line 375 in iwpriv.c for the
> existing example of IW_PRIV_TYPE_FLOAT.
> This could be adapted for this purpose (IW_PRIV_TYPE_BITRATE ?)
> and (mis)use the iw_freq structure to pass the values and extra info.

Ok. And then we will need to parse that data into format suitable for
prism54 in prism54 driver, and into format suitable for acx100/acx111
in acx100 driver, etc... Most probably this code will be ugly, because
different hardware have completely different way of setting tx rate.
Even acx100 and acx111 are different, not to say acx100 and prism54.
--
vda

Re: [Prism54-devel] Re: [PATCH/RFC] set_rates support for prism54

[Vladimir Kondratiev]

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

I would not mix rates with modulation and other channel parameters.
It looks better to bind frequency with parameters like modulation, channel 
width (10Mzh narrow channels in japan) etc. , into 'channel' number or 
(channel,band) tuple.

For supported and optional rate, IE (info element) format may be the best 
choice.

On Sunday 15 August 2004 19:10, Denis Vlasenko wrote:
DV> On Sunday 15 August 2004 16:21, Margit Schubert-While wrote:
DV> > I disagree with this.
DV> > We don't need parameter parsing either in the driver or in
DV> > wireless.c.
DV> > There is a perfectly good infrastructure in wireless tools iwpriv.c
DV> > Take a look at around line 375 in iwpriv.c for the
DV> > existing example of IW_PRIV_TYPE_FLOAT.
DV> > This could be adapted for this purpose (IW_PRIV_TYPE_BITRATE ?)
DV> > and (mis)use the iw_freq structure to pass the values and extra info.
DV>
DV> Ok. And then we will need to parse that data into format suitable for
DV> prism54 in prism54 driver, and into format suitable for acx100/acx111
DV> in acx100 driver, etc... Most probably this code will be ugly, because
DV> different hardware have completely different way of setting tx rate.
DV> Even acx100 and acx111 are different, not to say acx100 and prism54.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Re: [PATCH/RFC] set_rates support for prism54

[Denis Vlasenko]

On Sunday 15 August 2004 19:48, Vladimir Kondratiev wrote:
> I would not mix rates with modulation and other channel parameters.
> It looks better to bind frequency with parameters like modulation, channel
> width (10Mzh narrow channels in japan) etc. , into 'channel' number or
> (channel,band) tuple.

Consider need of being able to:

set_rates "1,2 5p,11p,22p" - i.e. "use PBCC modulation"
set_rates "1,2 5,11,22p" - "use standard CCK, and PBCC only for 22Mbit"

See? Very similar, but not the same.
So, how do you propose to express this?

This need is not imagined by me, it is very real for acx100
owners.

> For supported and optional rate, IE (info element) format may be the best
> choice.

I did not quite understand you, can you elaborate a bit?
--
vda

Re: [Prism54-devel] Re: [PATCH/RFC] set_rates support for prism54

[Vladimir Kondratiev]

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

DV> > For supported and optional rate, IE (info element) format may be the
 best DV> > choice.
DV>
DV> I did not quite understand you, can you elaborate a bit?

How card know what rates it can use? It parses "supported rates" IE (info 
element) from beacon it gets from AP. My point, it is reasonable to use the 
same language to specify further restrictions. This way, we will speak the 
same language as standard do.

In standard, there is no way to say "you can use PBCC, but not for rate 5.5". 
PBCC is either permitted or not. For "good" hardware, there is no point of 
doing this. You may need to artificially restrict rate/modulation only if 
hardware can't find best for current channel conditions, or, of course, for 
debug. But, I would say, for this cases, let's use debug hooks. Mainline 
should be as close to standard as possible.

It should be as generic as possible, also. Scheme you suggested is not very 
scalable. Think of TGn that would for sure add its tricks with modulation. If 
we start combining rate with modulation, we will shortly fall into too many 
options.

Does it clarify my point?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Re: [PATCH/RFC] set_rates support for prism54

[Denis Vlasenko]

On Sunday 15 August 2004 21:41, Vladimir Kondratiev wrote:
> DV> > For supported and optional rate, IE (info element) format may be the best
> DV> > choice.
> DV>
> DV> I did not quite understand you, can you elaborate a bit?
>
> How card know what rates it can use? It parses "supported rates" IE (info
> element) from beacon it gets from AP. My point, it is reasonable to use the
> same language to specify further restrictions. This way, we will speak the
> same language as standard do.

And advantages of doing that are .... ?

> In standard, there is no way to say "you can use PBCC, but not for rate
> 5.5". PBCC is either permitted or not. For "good" hardware, there is no
> point of doing this. You may need to artificially restrict rate/modulation
> only if hardware can't find best for current channel conditions, or, of
> course, for debug. But, I would say, for this cases, let's use debug hooks.

You can consider set_rates a debug hook. For 'normal' use, just
stick to "iwconfig rate" command.

> Mainline should be as close to standard as possible.

802.11 does not say anything about OS interface to setting basic
and operational rates. We are free to inmplement whatever we like.

Of course, I do not propose sending anything non-standard.

> It should be as generic as possible, also. Scheme you suggested is not very
> scalable.

It's much better than what we have now. "iwconfig rate" cover
only a subset of AP configuration needs. How can I, say,
diasllow 1 and 2 Mbit/s with iwconfig?

> Think of TGn that would for sure add its tricks with modulation.
> If we start combining rate with modulation, we will shortly fall into too
> many options.

I don't know what is TGn... sorry... However, adding new suffixes
would not be a problem at all.
--
vda