From: Arend Van Spriel <arend.vanspriel@broadcom.com>
To: Dmitry Shmidt <dimitrysh@google.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
linux-wireless@vger.kernel.org
Subject: Re: [PATCH] RFC: Universal scan proposal
Date: Fri, 9 Dec 2016 12:10:46 +0100 [thread overview]
Message-ID: <25da1ebe-5884-2bd9-0675-d414f954810a@broadcom.com> (raw)
In-Reply-To: <CAH7ZN-wGseBVzV3Vuq+6=kgaSL7e0UnndGXPdu4PQKZw8H47YQ@mail.gmail.com>
On 8-12-2016 23:35, Dmitry Shmidt wrote:
> On Wed, Dec 7, 2016 at 12:51 PM, Arend Van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>> On 7-12-2016 19:39, Dmitry Shmidt wrote:
>>> On Tue, Dec 6, 2016 at 10:44 PM, Johannes Berg
>>> <johannes@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
next prev parent reply other threads:[~2016-12-09 11:10 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-16 22:47 [PATCH] RFC: Universal scan proposal dimitrysh
2016-11-17 20:56 ` Arend Van Spriel
2016-11-18 23:53 ` Dmitry Shmidt
2016-11-22 7:24 ` Luca Coelho
2016-11-22 17:29 ` Dmitry Shmidt
2016-11-22 20:41 ` Arend Van Spriel
2016-11-22 20:54 ` Dmitry Shmidt
2016-11-23 8:43 ` Arend Van Spriel
2016-11-28 19:25 ` Dmitry Shmidt
2016-12-05 14:28 ` Johannes Berg
2016-12-05 18:32 ` Dmitry Shmidt
2016-12-07 6:44 ` Johannes Berg
2016-12-07 18:39 ` Dmitry Shmidt
2016-12-07 20:51 ` Arend Van Spriel
2016-12-08 22:35 ` Dmitry Shmidt
2016-12-09 11:10 ` Arend Van Spriel [this message]
2016-12-13 16:06 ` Johannes Berg
2017-01-03 20:45 ` Dmitry Shmidt
2017-01-04 13:28 ` Johannes Berg
2017-01-04 20:32 ` Dmitry Shmidt
2017-01-05 11:46 ` Johannes Berg
2017-01-05 13:39 ` Arend Van Spriel
2017-01-05 13:44 ` Johannes Berg
2017-01-05 19:59 ` Arend Van Spriel
2017-01-09 10:48 ` Johannes Berg
2017-01-09 12:07 ` Arend Van Spriel
2017-01-11 13:14 ` Johannes Berg
2017-01-05 20:45 ` Dmitry Shmidt
2017-01-09 10:45 ` Johannes Berg
2017-01-09 11:19 ` Arend Van Spriel
2016-12-13 16:04 ` Johannes Berg
2016-12-21 10:20 ` [RFC] nl80211: allow multiple active scheduled scan requests Arend van Spriel
2017-01-02 10:44 ` Johannes Berg
2017-01-03 12:25 ` Arend Van Spriel
2017-01-04 9:59 ` Johannes Berg
2017-01-04 10:20 ` Arend Van Spriel
2017-01-04 10:30 ` Johannes Berg
2017-01-04 10:34 ` Arend Van Spriel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=25da1ebe-5884-2bd9-0675-d414f954810a@broadcom.com \
--to=arend.vanspriel@broadcom.com \
--cc=dimitrysh@google.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).