Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <2861463e-a097-7efe-bc75-f13c8faf9547@quicinc.com>
Date:   Wed, 21 Dec 2022 09:33:14 +0530
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.0
Subject: Re: [PATCH] wifi: ath11k: Optimize 6 GHz scan time
Content-Language: en-US
To:     Marcel Holtmann <marcel@holtmann.org>
CC:     <ath11k@lists.infradead.org>, <linux-wireless@vger.kernel.org>
References: <20221220043823.20382-1-quic_mpubbise@quicinc.com>
 <5DAEA8B2-2B44-4A91-9E57-12B6C6B6C1FC@holtmann.org>
From:   Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
In-Reply-To: <5DAEA8B2-2B44-4A91-9E57-12B6C6B6C1FC@holtmann.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 12/20/2022 6:36 PM, Marcel Holtmann wrote:
> Hi Manikanta,
> 
>> Currently, time taken to scan all supported channels on WCN6750
>> is ~8 seconds and connection time is almost 10 seconds. WCN6750
>> supports three Wi-Fi bands (i.e., 2.4/5/6 GHz) and the numbers of
>> channels for scan come around ~100 channels (default case).
>> Since the chip doesn't have support for DBS (Dual Band Simultaneous),
>> scans cannot be parallelized resulting in longer scan times.
>>
>> Among the 100 odd channels, ~60 channels are in 6 GHz band. Therefore,
>> optimizing the scan for 6 GHz channels will bring down the overall
>> scan time.
>>
>> WCN6750 firmware has support to scan a 6 GHz channel based on co-located
>> AP information i.e., RNR IE which is found in the legacy 2.4/5 GHz scan
>> results. When a scan request with all supported channel list is enqueued
>> to the firmware, then based on WMI_SCAN_CHAN_FLAG_SCAN_ONLY_IF_RNR_FOUND
>> scan channel flag, firmware will scan only those 6 GHz channels for which
>> RNR IEs are found in the legacy scan results.
>>
>> In the proposed design, based on NL80211_SCAN_FLAG_COLOCATED_6GHZ scan
>> flag, driver will set the WMI_SCAN_CHAN_FLAG_SCAN_ONLY_IF_RNR_FOUND flag
>> for non-PSC channels. Since there is high probability to find 6 GHz APs
>> on PSC channels, these channels are always scanned. Only non-PSC channels
>> are selectively scanned based on cached RNR information from the legacy
>> scan results.
>>
>> If NL80211_SCAN_FLAG_COLOCATED_6GHZ is not set in the scan flags,
>> then scan will happen on all supported channels (default behavior).
> 
> is this really a good idea? The interpretation on what scan results will
> be reported would be preferable the same no matter what hardware is
> present. Why would ath11k now have a different behavior?
> 
> And more important, why is this something driver or even Linux kernel
> specific. Let userspace select the frequencies to scan.
> 

By the way, userspace itself selects the frequencies to scan, not the 
driver.

If we see the split scan implementation in cfg80211, this is the how it 
is implemented. If NL80211_SCAN_FLAG_COLOCATED_6GHZ is set, it selects 
all PSC channels and those non-PSC channels where RNR IE information is 
found in the legacy scan results. If this flag is not set, all channels 
in 6 GHz are included in the scan freq list. It is upto userspace to 
decide what it wants.

> Looks like that iwd and wpa_supplicant set this flag regardless which
> means to me that a driver should respect the requested frequencies to
> be scanned.
> 
> Anyhow, if you worry about time-to-connect, then fix userspace to be
> smart with scanning. I am also confused on how a savings of 1.5 seconds
> out of 8 seconds is significant.

Most of the times, we see ~2 seconds of savings. 2 seconds of scan time 
improvement out of 8 seconds is about 25% improvement and this is indeed 
significant.

8 seconds of time I'm talking here is for passive scan when the 
regdomain is set to WORLD. If correct regdomain is set and channel flags 
are proper, then the time it takes to complete scan & connection is much 
lesser with this change. It is around 4 seconds.

  It still means you spent 6+ seconds
> in the 2.4 GHz and 5 GHz bands. I assume that you spent most time in
> 5 GHz right now.
> 
> I highly doubt that a 6+ seconds plus 2 seconds connection time is
> anywhere acceptable
As I said before, this is the worst case scenario. Active scan and 
connection on legacy band takes less than 4 seconds in normal usecase.

  Have you tried using iwd and see what the
> connection time actually is after initial connection.
> 

Not really, I'll try it out. Thanks for the suggestion.

Thanks,
Manikanta