Re: [Regression] rt2800usb - Wifi performance issues and connection drops

From: Alexander Wetzel <alexander@wetzel-home.de>
To: Felix Fietkau <nbd@nbd.name>,
	Linux regressions mailing list <regressions@lists.linux.dev>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Thomas Mann <rauchwolke@gmx.net>,
	Stanislaw Gruszka <stf_xl@wp.pl>,
	Helmut Schaa <helmut.schaa@googlemail.com>,
	Johannes Berg <johannes.berg@intel.com>
Subject: Re: [Regression] rt2800usb - Wifi performance issues and connection drops
Date: Wed, 8 Mar 2023 12:41:26 +0100	[thread overview]
Message-ID: <cfa5cc30-bf5a-bffd-4c2f-eec8a6522dd5@wetzel-home.de> (raw)
In-Reply-To: <4a02173f-3a60-0a7e-8962-3778e6c55bf3@nbd.name>

On 08.03.23 08:52, Felix Fietkau wrote:

>> I'm also planning to provide some more debug patches, to figuring out
>> which part of commit 4444bc2116ae ("wifi: mac80211: Proper mark iTXQs
>> for resumption") fixes the issue for you. Assuming my understanding
>> above is correct the patch should not really fix/break anything for
>> you...With the findings above I would have expected your git bisec to
>> identify commit a790cc3a4fad ("wifi: mac80211: add wake_tx_queue
>> callback to drivers") as the first broken commit...
> I can't point to any specific series of events where it would go wrong, 
> but I suspect that the problem might be the fact that you're doing tx 
> scheduling from within ieee80211_handle_wake_tx_queue. I don't see how 
> it's properly protected from potentially being called on different CPUs 
> concurrently.
> 
> Back when I was debugging some iTXQ issues in mt76, I also had problems 
> when tx scheduling could happen from multiple places. My solution was to 
> have a single worker thread that handles tx, which is scheduled from the 
> wake_tx_queue op.
> Maybe you could do something similar in mac80211 for non-iTXQ drivers.
> 

I think it's already doing all of that:
ieee80211_handle_wake_tx_queue() is the mac80211 implementation for the 
wake_tx_queue op. The drivers without native iTXQ support simply link it 
to this handler.

Alexander