[PATCH] wifi: ath11k: Optimize 6 GHz scan time

Manikanta Pubbisetty quic_mpubbise at quicinc.com
Mon Feb 27 02:57:09 PST 2023


On 2/27/2023 1:55 PM, Peer, Ilan wrote:
> Hi,
> 
>> -----Original Message-----
>> From: Manikanta Pubbisetty <quic_mpubbise at quicinc.com>
>> Sent: Monday, February 27, 2023 06:24
>> To: Johannes Berg <johannes at sipsolutions.net>; James Prestwood
>> <prestwoj at gmail.com>; Marcel Holtmann <marcel at holtmann.org>
>> Cc: ath11k at lists.infradead.org; linux-wireless at vger.kernel.org; Peer, Ilan
>> <ilan.peer at intel.com>
>> 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



More information about the ath11k mailing list