Re: [PATCH 1/2] nl80211: add support to enable/disable bss color collision detection

From: Nicolas Cavallari <Nicolas.Cavallari@green-communications.fr>
To: Lorenzo Bianconi <lorenzo@kernel.org>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	Rameshkumar Sundaram <quic_ramess@quicinc.com>,
	ath11k@lists.infradead.org, linux-wireless@vger.kernel.org
Subject: Re: [PATCH 1/2] nl80211: add support to enable/disable bss color collision detection
Date: Fri, 20 Jan 2023 17:10:04 +0100	[thread overview]
Message-ID: <17d8494a-ebae-e317-6096-c8621d0f33e3@green-communications.fr> (raw)
In-Reply-To: <Y8q5Z98S3pODD77W@lore-desk>

On 20/01/2023 16:55, Lorenzo Bianconi wrote:
>> On 19/01/2023 15:02, Johannes Berg wrote:
>>> On Mon, 2022-12-26 at 14:03 +0530, Rameshkumar Sundaram wrote:
>>>> As per 802.11ax-2021, STAs shall process BSS Color Change Announcement
>>>> (BCCA) from AP and switch to new color, but some STAs aren't processing
>>>> BCCA from AP and not doing color switch, causing them to drop data
>>>> frames from AP post color change.
>>>>
>>>> Provide an option to disable color collision detection and therefore
>>>> not to do BCCA to mitigate the same from AP. If it's required in case
>>>> where STA supports BCCA handling, then it can enabled in AP using this
>>>> option.
>>>>
>>>
>>> You should probably split this into cfg80211 and mac80211.
>>>
>>> Also, this doesn't really seem to make a lot of _sense_ since nothing in
>>> the kernel actually acts on detection of a color collision - hostapd is
>>> acting on that.
>>>
>>> So since you can easily make hostapd ignore the event, why do you even
>>> need this?
>>
>> This may not be related, but the software color collision detection sends a
>> netlink message for every colliding frame and it can hose up the system if
>> the other network is very active.
>>
>> Also, cfg80211_bss_color_notify() complains that the wdev lock isn't held.
> 
> Hi Nicolas,
> 
> I agree, I think we can ratelimit netlink messages sent by the kernel to
> userspace (e.g. to hostapd), I would say every 500ms is ok.
> I guess we can move cfg80211_obss_color_collision_notify() in a dedicated
> delayed_work so we can grab wdev mutex (cfg80211_obss_color_collision_notify is
> currently running in interrupt context).
> To give an idea, what do you think about patch below? (please note it is just
> compiled tested so far).

I think it should fix the problem, I'll try to test it.

Thanks!

> Regards,
> Lorenzo

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k