Return-path: Received: from mail-io0-f176.google.com ([209.85.223.176]:34192 "EHLO mail-io0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752295AbcLHWfF (ORCPT ); Thu, 8 Dec 2016 17:35:05 -0500 Received: by mail-io0-f176.google.com with SMTP id p42so29649872ioo.1 for ; Thu, 08 Dec 2016 14:35:05 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <93d4475c-58bd-d497-3347-a988d551f374@broadcom.com> References: <94eb2c110db85c2379054172dad0@google.com> <1480948100.31788.15.camel@sipsolutions.net> <1481093061.4092.17.camel@sipsolutions.net> <93d4475c-58bd-d497-3347-a988d551f374@broadcom.com> From: Dmitry Shmidt Date: Thu, 8 Dec 2016 14:35:03 -0800 Message-ID: (sfid-20161208_233510_837371_A824733A) Subject: Re: [PATCH] RFC: Universal scan proposal To: Arend Van Spriel Cc: Johannes Berg , linux-wireless@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Wed, Dec 7, 2016 at 12:51 PM, Arend Van Spriel wrote: > On 7-12-2016 19:39, Dmitry Shmidt wrote: >> On Tue, Dec 6, 2016 at 10:44 PM, Johannes Berg >> 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. >> >>>> 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? > 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? > Regards, > Arend