Johannes Berg <johannes@xxxxxxxxxxxxxxxx> writes: > 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. Yeah. I'll keep this in mind when I implement the airtime fairness accounting. >> > 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. Yes, and I figure giving the driver that option might be a good way to have some flexibility. -Toke
