Re: [PATCH][RFC] nl80211/mac80211: Rounded RSSI reporting

[Denis Kenzior <denkenz@gmail.com>]

Hi Johannes,

 > Huh? No, beacon filtering is implemented by a lot of drivers today.

Pardon a dumb question, but can filtering be turned off?  I doubt anyone 
would want to, but just wondering.

>
>> The userspace switches count too and are the main motivation for this
>> patch.  Eventually, as you say, things will depend on specific
>> drivers and you will want to optimise whatever you can assuming the
>> hardware you're constrained to.
>
> Yes and no. I think we can probably define a reasonable subset that
> you'd expect more devices to implement. I don't really see the
> requirement to do the "banding" that you did here offloaded - doing it
> in mac80211 won't help much, and won't work in cases where you have
> beacon filtering already anyway.

Is there anything you have in mind?  Our goal is to minimize 
hardware-kernel-userspace wakeups.  With the nl80211 API as it is today, 
it doesn't seem feasible to do anything besides polling.  Whatever we 
come up with will surely be better than that.

> Well, ok, technically the API can be implemented on top of drivers with
> low/high thresholds, by doing the configuration according to the
> current range you're in.

So you're thinking of having high and low threshold.  So we'd get an 
event when we're higher than the high threshold and lower than the low 
threshold, right?  Then we'd need to bootstrap our current rssi somehow, 
or do we get another event?  I'm guessing we're going to have some race 
condition issues?

>
> I would argue though that it makes more sense to expose a simpler
> capability (e.g. two instead of the current single threshold) and do
> the reprogramming from higher layers. That ends up being more flexible,
> since you can then, for example, also have ranges that aren't all
> identical - which makes some sense because above a certain level you
> don't really care at all.

It seems like we'd be limiting ourselves here.  Couple reasons that come 
to mind:
- This would still require user space to keep re-setting the new 
thresholds.  While the wakeups are much less frequent than with polling 
for example, they still add up.  Scheduling userspace, processing 
nl80211 messages, etc is still a cost.
- It feels like we're exposing a lowest-common-denominator API with no 
possibility of offload / optimization in the future.  E.g. even drivers 
that can support arbitrary number of thresholds will be boxed in.

Would using an n-threshold API be possible?  That way user space can 
program in whatever threholds once, and then the kernel would figure out 
how to support that given the relevant hardware capabilities.

>
>> In short a nl80211 change would be needed regardless of the mechanism
>> chosen.
>
> Agree. I'm just not convinced that the banding mechanism you propose is
> the most reasonable choice for new API.
>

Understood, but it was just a stab in the dark to get this discussion 
started.

Regards,
-Denis