On Tue, 2023-03-14 at 17:44 +0100, Alexander Wetzel wrote:
Have you considered Felix's proposal of having a separate thread to handle all the transmits? Or maybe that's too much for stable too?
I was planning to respond to Felix mail, too. But guess it makes more sense here now and not have multiple concurrent discussions:-)
:-)
For the immediate fix I do not like the kthread. Which simply may be due to the fact that I would need more time to delve into that.
Agree.
Not so sure how we can get the queue wakes as cheap as they currently are, though. Each time we kick off the kthread it would have to check the scheduling lists for each AC. Or use one kthread per AC... (That from someone who knows close to nothing about kthread and needs do more reading...)
Yes it might not be as cheap, but a kthread could also handle multiple packets together if there were many enqueued, so might be even be a net win in a kind of high traffic case. Not sure.
Generally it sounds like improvement for mac80211 roadmap. But nothing I would want to pickup right now. I first want to wrap up the migration to iTXQ. (Which now also redesigns how filtered and pending frames are handled, btw.)
Also agree with that.
I'll just use per-ac spinlocks in ieee80211_handle_wake_tx_queue(), allowing multiple ACs to TX at the same time.
Not sure it's even worth splitting it across ACs?
That's probably not able to prevent the stopped queue issue Thomas got with 6.2 kernels when mutliply ACs have concurrent TX. But it will bring back the driver to the level it operated on kernel <6.1. Which sounds acceptable for me.
Sure.
Someone planning to fix the issue for ath10k? If not I'll look into that, too. (Since we don't have known issues for that it's not exactly a priority.)
Not me, already have my hands full with iwlwifi :-)
johannes