Message-ID: <42185fa2-4191-fcf5-9c0f-fd7098bb856b@nbd.name>
Date:   Wed, 8 Mar 2023 12:57:26 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.8.0
Subject: Re: [Regression] rt2800usb - Wifi performance issues and connection
 drops
Content-Language: en-US
To:     Alexander Wetzel <alexander@wetzel-home.de>,
        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>
References: <b8efebc6-4399-d0b8-b2a0-66843314616b@leemhuis.info>
 <5a7cd098-1d83-6297-e802-ce998c8ec116@leemhuis.info>
 <6025e17e-4c29-6d36-6b9c-2fec543b21c4@wetzel-home.de>
 <debc7fe9-204d-63a7-aa61-91b20a46f385@wetzel-home.de>
 <4a02173f-3a60-0a7e-8962-3778e6c55bf3@nbd.name>
 <cfa5cc30-bf5a-bffd-4c2f-eec8a6522dd5@wetzel-home.de>
From:   Felix Fietkau <nbd@nbd.name>
In-Reply-To: <cfa5cc30-bf5a-bffd-4c2f-eec8a6522dd5@wetzel-home.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 08.03.23 12:41, Alexander Wetzel wrote:
> 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.
I know. The problem I see is that I can't find anything that guarantees 
that .wake_tx_queue_op is not being called concurrently from multiple 
different places. ieee80211_handle_wake_tx_queue is doing the scheduling 
directly, instead of deferring it to a single workqueue/tasklet/thread, 
and multiple concurrent calls to it could potentially cause issues.

- Felix