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

[Johannes Berg <johannes@sipsolutions.net>]

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

Generally I assume that a typical device/firmware will be able to turn
it off (I know ours can), but we don't think we even provide a knob for
it for anyone to request it, so you'd have to modify the driver.

> 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.

I was thinking of just providing two thresholds, since you should be
able to emulate more of them with that, without much cost.

> 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?  

I'm mostly handwaving, but yes.

> 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?

Generally, with CQM, when you initially program it you get an event
telling you where you're at right now - so hopefully you'd get "middle"
(rather than "low"/"high") with the actual signal falling squarely into
your range, and from there on you're pretty much good to go.

> 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.

That seems like a reasonable idea. We'd want to have code in cfg80211
that does the emulation as we discussed above, so that from a userspace
POV an "arbitrary" number of thresholds is supported (if the capability
is supported at all, which would depend on the device doing >=2
thresholds).

johannes