On 2/27/2023 1:55 PM, Peer, Ilan wrote:
Hi,
-----Original Message-----
From: Manikanta Pubbisetty <quic_mpubbise@xxxxxxxxxxx>
Sent: Monday, February 27, 2023 06:24
To: Johannes Berg <johannes@xxxxxxxxxxxxxxxx>; James Prestwood
<prestwoj@xxxxxxxxx>; Marcel Holtmann <marcel@xxxxxxxxxxxx>
Cc: ath11k@xxxxxxxxxxxxxxxxxxx; linux-wireless@xxxxxxxxxxxxxxx; Peer, Ilan
<ilan.peer@xxxxxxxxx>
Subject: Re: [PATCH] wifi: ath11k: Optimize 6 GHz scan time
On 2/24/2023 3:45 PM, Johannes Berg wrote:
On Fri, 2023-02-24 at 15:38 +0530, Manikanta Pubbisetty wrote:
On 1/10/2023 10:35 PM, James Prestwood wrote:
On Tue, 2023-01-10 at 10:49 +0530, Manikanta Pubbisetty wrote:
On 12/29/2022 2:52 AM, James Prestwood wrote:
Hi Manikanta,
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.
This isn't your problem, but it needs to be said:
The nl80211 docs need and update to reflect this behavior (or
remove the PSC logic). IMO this is really weird that the kernel
selects PSC's based on the co-located flag. The docs don't
describe this behavior and the flag's name is misleading (its not
SCAN_FLAG_COLOCATED_AND_PSC_6GHZ) :)
Sorry for the late reply, I was on vacation.
What you said make sense. The existing flag should not add PSC
channels according to the flag description.
We can add another flag something like you pointed out
SCAN_FLAG_COLOCATED_AND_PSC_6GHZ and include PSC channels if
this
flag is set. What do you say?
I'm no authority here, just wanted to point this out. This is
something that would need to be in mac80211 though, not just a specific
driver.
It would be up to the maintainers and would require changing the
behavior of the existing flag, which then changes behavior in
wpa_supplicant/hostapd. So its somewhat intrusive.
But personally I'd be for it. And just require userspace include
PSC's like any other channels if they need those.
Hi Johannes,
What is your opinion on the changes being proposed to the 6 GHz scan
in
cfg80211 that is being discussed in this thread?
I don't think we can/should change the semantics of an existing flag
now, but we can certainly update the documentation to match the
implementation, and add more flags to make it more flexible.
johannes
Sure, makes sense. I'll make the changes and send them out for review.
Sorry for joining this thread late. I agree that the documentation of the NL80211_SCAN_FLAG_COLOCATED_6GHZ
flag can be updated, but FWIW, I want to clarify the intention behind this flag:
First, the logic would always scan only the channels requested by user space, so if the PSC channels are
not included they would not be scanned.
Agreed.
Second, the intention of the NL80211_SCAN_FLAG_COLOCATED_6GHZ flag was to indicate to the kernel that
before going to scan the 6GHz channels it should first scan the 2GHz/5GHz bands such that it would retrieve information
about the collocated APs, so eventually it would only scan the given PSC channels and the channels on which collocated APs
are found (in which case direct probing of these APs is expected).
Understood, currently the documentation of the
NL80211_SCAN_FLAG_COLOCATED_6GHZ flag doesn't state this. It simply
scans all the PSC channels the user space has asked for whether they are
co-located or not. As you mentioned earlier, we need to fix the
documentation part.
While the PSC channels could have been scanned together with the 2GHz/5GHz channels, since collocated APs might also reside
on PSC channels, we wanted to avoid scanning PSC channels twice, so this is why they are scanned only after the scan on legacy
bands.
Hope this helps,
Understood, thanks a lot for the clarification.
Manikanta
