On 8-12-2016 23:35, Dmitry Shmidt wrote: > On Wed, Dec 7, 2016 at 12:51 PM, Arend Van Spriel > <arend.vanspriel@xxxxxxxxxxxx> wrote: >> On 7-12-2016 19:39, Dmitry Shmidt wrote: >>> On Tue, Dec 6, 2016 at 10:44 PM, Johannes Berg >>> <johannes@xxxxxxxxxxxxxxxx> wrote: >>>> >>>>> Indeed, results are results. I just want to take care of two things: >>>>> 1) Memory consumption - we can clear stale scan results for >>>>> connection, but not for location if we are using history scan. >>>> >>>> Well eventually we also have to clear for location if we run out of >>>> memory, that usually means dumping them out to the host, no? >>> >>> Being out of memory and consuming more memory are different >>> things, but I agree - maybe we don't need to worry about it. So does location use all information from the scan history or is it interested in some specific information, eg. rssi. >>>>> 2) Use of insufficient results for connection - in case we had >>>>> history or hotlist scan only for very limited amount of channels, >>>>> then we may not have enough APs in our result for "sterling" >>>>> connection decision. >>>> >>>> I'm not entirely sure about this case - surely noticing "we can do >>>> better now" is still better than waiting for being able to make the >>>> perfect decision? >>> >>> Maybe we can just keep flag saying that currently available results >>> were not received by usual full scan. >>> >>>>>>> Report: none / batch / immediate >>>>>> >>>>>> Not sure I see much point in "none"?? >>>>>> >>>>>> Can you define these more clearly? Do you think "batch" reporting >>>>>> should be like the gscan buckets? Or actually have full >>>>>> information? >>>>> >>>>> None - means that there is not need to report. It can be useful >>>>> in case of roaming scan, scheduling or hotlist scan - you didn't find >>>>> anything suitable - don't report that there is no scan results. >>>> >>>> But that seems more of a filtering thing, combined with "immediate" for >>>> anything passing the filter? >>> >>> We can use this approach as well. >>> >>>>>>> Request may have priority and can be inserted into >>>>>>> the head of the queue. >>>>>>> Types of scans: >>>>>>> - Normal scan >>>>>>> - Scheduled scan >>>>>>> - Hotlist (BSSID scan) >>>>>>> - Roaming >>>>>>> - AutoJoin >>>>>> >>>>>> I think somebody else said this but I didn't find it now - I think >>>>>> this would make more sense to define in terms of expected behaviour >>>>>> than use cases for each type of scan. >>>>> >>>>> I think Luca made this statement. >>>> >>>> Yeah - I just couldn't find it again on re-reading the thread :) >>>> >>>>> It is totally ok from SW point of >>>>> view - especially due to the fact that scan is scan. However, >>>>> I suspect it will be harder to handle from user experience. I mean >>>>> at the end wireless framework / driver / FW will convert special >>>>> scan type to usual scan with special params and response, but why >>>>> to put this burden on user? >> >> I don't think this will put burden on the user although it depends >> who/what you mean by this. If you mean the mere mortal end-user I would >> say no as indeed there must be some software entity (in user-space) that >> will have to initiate a nl80211 command with appropriate attributes >> according to whatever user-space is trying to accomplish. >> >>>> I just think it's more flexible and open-ended. The actual definition >>>> of the resulting parameters needs to be somewhere anyway - putting it >>>> into driver/firmware (vs. wifi framework or so) seems to duplicate it >>>> and certainly makes it harder to modify/extend in the future, no? >>> >>> So, let's summarize: >>> Instead of creating new type of generic scan with special types, >>> we want to go with additional expansion of scheduled scan options and >>> parameters (in order not to "multiply entities"), including ability to send >>> new scheduled scan request without stopping previous one. >>> >>> Is it Ok? >> >> Sounds ok. To me a generic scan command with type attribute is >> equivalent to having seperate commands for each type so there seems to >> be no gain. Now whether this all can be accomplished by extending the >> scheduled scan depends on the problem that you are trying to solve. >> >> Main purpose seems to be offloading different scanning tasks which could >> make scheduled scan a good candidate. Now I want to add gscan to this >> mix as it seems some concepts for that are in play in this discussion as >> well, eg. hotlist. gscan is like scheduled scan, but it supports >> multiple schedules. However, it is still a single request from a single >> user-space process. I think Luca mentioned supporting requests from >> different user-space processes. Is that also what you mean by "ability >> to send new scheduled scan request without stopping previous one" or is >> that still from a single user-space process. Do we need a limit to the >> amount of scheduled scan requests that can be handled simultaneously. > > Supporting requests (or more precisely requests and results) differentiated > by user-space entity can be tricky. Right now we are not checking current > caller pid, right? Maybe it is also good idea - or maybe we can just > make result filtering per user-space caller? There is already struct cfg80211_sched_scan_request::owner_nlportid * @owner_nlportid: netlink portid of owner (if this should is a request * owned by a particular socket) It is set in nl80211_start_sched_scan(): if (info->attrs[NL80211_ATTR_SOCKET_OWNER]) sched_scan_req->owner_nlportid = info->snd_portid; It basically links the life-time of the request to the socket connection if requested to do so. It is just not very useful with tools like iw. >> A maybe more important aspect of gscan is user-space control of result >> reporting and thus the frequency of waking up host and/or user-space. I >> suspect this would be needed in the scheduled scan extension as well, right? > > It will be always up to user-space caller to make system more or less > power-efficient, right? That depends on the API, right? If the API provides the knobs, than user-space can indeed make the decision. Regards, Arend >> Regards, >> Arend
