Johannes Berg <[email protected]> writes: > On Wed, 2018-09-05 at 14:32 +0200, Toke Høiland-Jørgensen wrote: >> Johannes Berg <[email protected]> writes: >> >> > On Wed, 2018-09-05 at 13:41 +0200, Johannes Berg wrote: >> > > On Wed, 2018-09-05 at 13:40 +0200, Toke Høiland-Jørgensen wrote: >> > > > >> > > > Guess we'll have to deal with everything else if we ever move >> > > > management >> > > > frames onto the TXQ path as well... >> > > >> > > Depends on whether we care for management frame priorities or not ... so >> > > far we haven't really. >> > >> > Actually, for the most part we have implemented that properly. Except >> > for the TXQ I added for bufferable management ... oh well, I think we're >> > the only user thereof now. >> > >> > I'm not sure we want to have a TXQ per TID for management, that seems >> > overkill. But I'm also not sure how to solve this otherwise ... >> >> Graft it to an existing TXQ, similar to how the fragments queue is used >> now? Saves a TXQ at the expense of having to special-case it... > > The problem isn't so much how we handle it in mac80211 for the queueing, > but how we deal with things like A-MSDU and how we present it to the > driver ... for iwlwifi at least we'd really like to have only data > frames so we can map it directly to the hardware queue ...
Ah, I see. No, then just putting them at the head of a different TXQ probably won't work... Are you mapping TXQs to hardware queues dynamically as they empty and re-fill? Presumably you'll have cases where you don't have enough HWQs? -Toke
