Re: [PATCH-v2 1/2] mac80211: Take bitrates into account when building IEs.

[Ben Greear <greearb@candelatech.com>]

On 02/18/2016 12:32 PM, Johannes Berg wrote:
> On Thu, 2016-02-04 at 09:52 -0800, Ben Greear wrote:
>> On 02/04/2016 01:02 AM, Johannes Berg wrote:
>>> On Tue, 2016-01-26 at 07:19 -0800, Ben Greear wrote:
>>>
>>>> As far as I can tell, that will not work, because I want to have
>>>> multiple station devices per radio, and have each of them be able
>>>> to
>>>> use a different configuration.  So, one station may be /g, and
>>>> another /n and another /AC.  Same with APs.  In addition, some
>>>> stations may want to use all available rates for their mode, and
>>>> others may want to use a fixed rate or subset of available rates.
>>>
>>> So let's agree that we're splitting the *used* rates (which we have
>>> today) and the *advertised* rates/modes/...
>>
>> Yes, I think that will work well, and unless I mis-understand, that
>> is basically what I implemented so far.
>
> Yes.
>
>> Copied state might be tricky.  I think if we hold any copies of
>> capabilities data in the sdata, then it should be logically compared
>> with a mask and then treated as an AND with whatever the wiphy has.
>
> Not sure what you're saying here. I was thinking we'd simply do one of
> these two:
>
> 1) sdata->sband[5GHZ].vht = wiphy->sband[5GHZ].vht & user-config
>     (semantically, not implementation of course)
> 2) sdata->sband[5GHZ].vht = wiphy->sband[5GHZ].vht
>
> and change mac80211 to use sdata->sband instead of wiphy->sband
> wherever the latter is used today. That way, we can avoid touching all
> these things.
>
> I think, for example, that you missed TDLS in your changes. Changing
> everything throughout would mean that grepping for "wiphy->sband" would
> immediately show such bugs, making it far easier to maintain.


I think option 1 might be better.  For option 2, I'd be worried about
someone changing the wiphy somehow and vdevs getting out of sync.

Any opinions on the lifetime for the sdata->sband_user_config data?

For instance, could be cleared when station dis-associates,
or we could make it persist until changed or until vdev goes away?

And, while this would take care of some of the issues (3x3 vs 2x2?), it still wouldn't
let someone have full control over the advertised rates vs configured-rates
and such, would it?

So, your proposal is in addition to allowing advertised-rates to be configured?

Thanks,
Ben

>>    I'm reluctant to propose any serious mac80211 change at this point,
>> though perhaps as more of this type of features are added, then it
>> will become more obvious how to nicely consolidate things in
>> mac80211.
>
> I don't really think this would be a "serious" change? It's basically
> pointering changes, you could (and perhaps should, to catch it all) use
> an spatch to make the initial change.
>
>> To be honest, I thought my -v2 patches were fairly non-invasive
>> compared to my normal hackings :)
>>
>
> :)
>
> johannes
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com