Sender: Larry Finger <larry.finger@gmail.com>
Message-ID: <eb4e2847-a0a3-5edc-dc3e-63e6d4d8bf28@lwfinger.net>
Date:   Thu, 9 Mar 2023 09:02:08 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.8.0
Subject: Re: Performance of rtw88_8822bu
Content-Language: en-US
To:     Dan Williams <dcbw@redhat.com>, Ping-Ke Shih <pkshih@realtek.com>,
        Sascha Hauer <s.hauer@pengutronix.de>
Cc:     linux-wireless <linux-wireless@vger.kernel.org>
References: <93d565e1-3a23-69f3-bedd-b71eb601bceb@lwfinger.net>
 <20230306091845.GC27249@pengutronix.de>
 <20230306125944.GD27249@pengutronix.de>
 <6ed1239f8c404dcb9d571771c230b69b@realtek.com>
 <2064a549-ef7a-98bf-cc24-a25b8571877f@lwfinger.net>
 <1f01b1ff59d7412aa7eafdce022d7635@realtek.com>
 <6e14212a414067c970b8d2d0bf6eb8df5319a972.camel@redhat.com>
From:   Larry Finger <Larry.Finger@lwfinger.net>
In-Reply-To: <6e14212a414067c970b8d2d0bf6eb8df5319a972.camel@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 3/8/23 10:43, Dan Williams wrote:
> On Wed, 2023-03-08 at 00:36 +0000, Ping-Ke Shih wrote:
>>
>> I think NM triggers scan operation when turning it on. Then, driver
>> switches channels
>> between AP and scan channels with flushing queue that causes timeout.
>> The cause is
>> still hard to transmit packets out, so TX buffer gets jammed.
> 
> Yes, (at least historically) nm-applet requests that NM perform a scan
> when you interact with it, on the theory that when you open the WiFi
> network menu you probably want to see recent scan results. Similar to
> MacOS's AirPort menu.
> 
> Most drivers handle that OK with intermittent traffic, but it will
> cause disruption if for high throughput and/or latency-sensitive
> traffic.
> 
> Dan
> 
>>
>> If you enlarge the retry count or timeout value of
>> __rtw_mac_flush_prio_queue(),
>> the timeout flushing could be disappear. Also, if we can implement
>> rtwdev->hci.ops->flush_queues for USB, the flushing log can be
>> reduced.

Dan: Thanks for confirming that a scan trigger was the likely cause of the 
problem. I verified that by adding a WARN_ONCE() after the warning was printed. 
The first part of the traceback was:
rtw_ops_flush
__ieee89211_flush_queues
ieee80211_offchannel_stop_vifs
__ieee80211_start_scan
__ieee80211_request_scan
rdev_scan
nl80211_trigger_scan

Ping-Ke: Increasing the time waiting for the queue to flush did not help. I 
increased the loop count from 5 to 50, and the sleep time from 20 to 200 msec. I 
also tested exiting as soon as "avail" was greater than zero. I also tested 
unlocking the mutex before the msleep() and relocking it afterward. Nothing 
changed the behavior. It appears that something else is locking the queue 
clearing, and that no amount of delay will help.

I will be trying to write a USB version of the flush queues routine based on the 
PCI code.

Sasha: I agree that no load is required to trigger the problem.

There are no simple problems!

Larry