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
