Re: [PATCH] wifi: mac80211: Serialize calls to drv_wake_tx_queue()

[Johannes Berg <johannes@sipsolutions.net>]

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