Johannes Berg <johan...@sipsolutions.net> writes: > On Sat, 2018-09-08 at 00:22 +0200, Toke Høiland-Jørgensen wrote: >> >> A few things that were discussed in the last round that I did *not* change: > > Thanks for this list btw. > >> - I did not add any locking around next_txq(); the driver is still supposed >> to maintain a lock that prevents two threads from trying to schedule the >> same AC at the same time. This is what drivers already do, so I figured it >> was easier to just keep it that way rather than do it in mac80211. > > I'll look at this in the code, but from a maintainer perspective I'm > somewhat worried that this will lead to issues that are really the > driver's fault, but surface in mac80211. I don't know how easy it > would be to catch that.
Yeah, I get what you mean. The alternative would be to have a ieee80211_start_schedule(ac) and ieee80211_end_schedule(ac), which basically just takes a lock. Would mean we could get rid of the 'first' parameter for next_txq(), so might not be such a bad idea; and if the driver has its own locking the extra locking in mac80211 would just be an always-uncontested spinlock, which shouldn't be much overhead, right? -Toke
