[PATCH 00/11] Initial sched_scan support in wpa_supplicant

[Bondar, Alexander]

Hi Luciano, some comments below

> * I have implemented a rather simple algorithm that is used when we
>   need to scan for more than the maximum SSIDs supported by the
>   driver.  In this case, we need to eventually stop the sched_scan and
>   start a new one with the remaining SSIDs.  In this implementation, I
>   always start with a timeout of max_sched_scan_ssids * 2 seconds and
>   an interval of 2 seconds.  After the timeout, I double the scan
>   interval and halve the timeout.  This backing off algorithm is used
>   because the SSIDs are supposedly sorted in order of importance, so
>   we spend less time and with longer intervals when scanning lower
>   priority SSIDs.
>
>   => I think this is good enough for now and can be changed in the
>      future if someone comes up with a better algorithm.

An assumption that SSIDs are sorted in order of importance is not always correct. For example, in Android based smartphone you 
will find networks stored in occasional order. In this case probably more suitable algorithm is to pick SSIDs in some arbitrary (random?) order.
Would we think about some scalable mechanism in WPA supplicant that allows everyone to implement its own algorithm on how to 
overcome maximum SSIDs limitation?

> * We only perform sched_scans when the wpa_supplicant is starting and
>   when a connection fails or we disconnect.  We don't perform
>   scheduled scans yet when the SSID list is changed, an SSID is
>   enabled or on other scan scenarios.  This should be fairly simple to
>   add, but I want to maturize the current use-case first.
>
>   => I'll send a patch in the near future to address the other scan
>   scenarios.  For now, the most important use-cases are handled and,
>   in any case, most of the other scenarios should work indirectly.

Periodic scan, both unassociated and associated are probably most suitable use cases for sched_scan. When idle associated we can reduce 
power consumption by offloading periodic scan to device. Bgscan module may call sched_scan_request instead of scheduling periodic scan by itself. 
Another concern is canceling sched_scan. For example, we want to cancel sched_scan when user initiated scan request happens.
Canceling itself is asynchronous flow, so we need to implement some logics in EVENT_SCHED_SCAN_STOPPED to complete the original flow.

Thanks
   ~Alex
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.