On 8-12-2016 18:52, Malinen, Jouni wrote: > On Wed, Dec 07, 2016 at 09:03:23PM +0100, Arend Van Spriel wrote: >> On 7-12-2016 10:33, Vamsi, Krishna wrote: >>>> -----Original Message----- >>>> From: Johannes Berg [mailto:johannes@xxxxxxxxxxxxxxxx] >>> >>>> What about Arend's comment regarding this functionality overlapping with the >>>> BSS selection offload configuration? >>>> >>>> Do you think there's any ability to share attributes/functionality? >>> >>> Hi Johannes, >>> >>> I think the later comment from Luca on this which I pasted below is more agreeable. >>> >>> Yes, similar but not quite the same. The existing case is for finding BSSs that are worth waking the host up for (while disconnected), so it needs to be better than the RSSI passed (absolute number). Now this is about relative RSSI as compared to the current connection, so RELATIVE_RSSI is different than RSSI and I think the same attribute should not be used, to avoid confusion. >> >> I noticed the response from Luca, but did not get back on this. I know >> it is not the same, but what I meant is whether we could extend it so it >> also covers your scenario. > > I'm not sure I see the point of trying to avoid the new RELATIVE_RSSI > attribute. We need to clearly specify that this new constraint is indeed > for relative comparison against the currently connected BSS. Hi Jouni, I am not saying it should be avoided. Just looking at it conceptually the scheduled scan request holds so-called matchsets that specify the constraints to determine whether a BSS was found that is worth notifying the host/user-space about. As such I would expect the relative RSSI attribute(s) to be part of the matchset. That way you can specify it together with the currently connected SSID in a single matchset. > As far as your second email is concerned, it might make more sense to > use the existing NL80211_ATTR_BSS_SELECT instead of the new > NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF since they cover very > similar purpose in defining RSSI preference between bands. We can take a > look at doing so. One thing to be a careful about this is in what claims > there are about using NL80211_ATTR_BSS_SELECT for capability indication > in GET_WIPHY. I guess we can leave that as-is to apply for _CONNECT and > the new EXT_FEATURE flag we are adding for sched_scan applies for this > attribute in SCHED_SCAN. The NL80211_ATTR_BSS_SELECT supports different methods for BSS selection. One of them being RSSI_ADJUST which is similar to this. It lets user-space specify the band and adjustment instead of having a band implied in the attribute name. Agree that if reusing it for scheduled scan you would still need the EXT_FEATURE flag. Regards, Arend
