On Tue, 2017-10-10 at 19:51 +0200, Toke Høiland-Jørgensen wrote: > > > + struct list_head active_txqs; > > > + spinlock_t active_txq_lock; > > > > Is there much point in having a separate lock? We probably need the > > fq lock in most places related to this anyway? > > Well, once the scheduler gets a bit smarter it may be necessary to > much with the order of TXQs on there without touching any of the > queues (e.g., when calculating airtime usage on TX and RX > completion). Not sure if that is enough to warrant a separate lock, > though; I hadn't thought about just grabbing fq->lock... Ok, dunno. It seemed sort of related but perhaps it's not really. > > Also maybe you should only do that if the TXQ isn't *empty*, so the > > driver could call this unconditionally? > > There can be cases where the driver wants the queue to be scheduled > even though it looks empty from mac80211's point of view. For ath9k, > the driver keeps its retry queue in the drv_priv part of the txq > structure, so it will check if that is empty before deciding to call > the schedule function. > > This is also related to the PS behaviour, so guess this could be > changed once that is all TXQ-based... Interesting. I guess scheduling an empty queue doesn't really matter for mac80211 anyway though - just some extra work if we try to get frames from it. johannes
