[Make-wifi-fast] [PATCH RFC v3 0/4] Move TXQ scheduling into mac80211
johannes at sipsolutions.net
Mon Sep 10 07:26:29 EDT 2018
On Mon, 2018-09-10 at 13:17 +0200, Toke Høiland-Jørgensen wrote:
> > > - 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.
And I guess start would increment the schedule number, which is now
dependent on first
> Would mean we could get rid of the 'first'
> parameter for next_txq(), so might not be such a bad idea;
Right, that's what I meant.
> 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?
It may still bounce around CPUs if you call this from other places, but
I suspect that wouldn't be the biggest issue. There are a lot of
calculations going on too...
More information about the Make-wifi-fast