On 8-12-2016 23:35, Dmitry Shmidt wrote:
> On Wed, Dec 7, 2016 at 12:51 PM, Arend Van Spriel
> <arend.vanspr...@broadcom.com> wrote:
>> On 7-12-2016 19:39, Dmitry Shmidt wrote:
>>> On Tue, Dec 6, 2016 at 10:44 PM, Johannes Berg
>>> <johan...@sipsolutions.net> 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
