On Fri, 2016-10-21 at 19:03 +0000, Zaborowski, Andrew wrote: > > The problem is that you really want this to be offloaded to the > > device, *especially* if you care about low power usage, because you > > absolutely don't want to be processing each beacon (which is > > typically what we derive the data from today) in the host CPU - you > > want those to be filtered by the device so you don't wake up the > > host CPU every ~102ms. > > Right, that would be a separate optimisation but it probably won't > arrive until there's an API that the drivers can implement, so I > think this is a prerequisite. Huh? No, beacon filtering is implemented by a lot of drivers today. > 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. Drivers like iwlwifi would be able to implement the banding in software, since they get a notification on every change above a configurable threshold, but other drivers like one I looked at actually do have a low and high threshold today, and program them to be the same value with our current CQM API definitions. > It seems like any mechanism you choose can be implemented on top of > hardware that supports a low and a high threshold by setting the next > values while handling the event related to the previous threshold > crossing event. If the thresholds are specified by a middle value > and a hysteresis or distance, that would work equally well. > The API I added in the patch also allows offloading to such hardware. 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. 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. > 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. johannes
