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;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: [PATCH] wifi: ath11k: Optimize 6 GHz scan time
From:   Marcel Holtmann <marcel@holtmann.org>
In-Reply-To: <20221220043823.20382-1-quic_mpubbise@quicinc.com>
Date:   Tue, 20 Dec 2022 14:06:26 +0100
Cc:     ath11k@lists.infradead.org, linux-wireless@vger.kernel.org
Content-Transfer-Encoding: 7bit
Message-Id: <5DAEA8B2-2B44-4A91-9E57-12B6C6B6C1FC@holtmann.org>
References: <20221220043823.20382-1-quic_mpubbise@quicinc.com>
To:     Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
Precedence: bulk

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.

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. 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. Have you tried using iwd and see what the
connection time actually is after initial connection.

Regards

Marcel