Johannes Berg <johannes@xxxxxxxxxxxxxxxx> writes: > On Wed, 2018-08-29 at 11:22 +0200, Toke Høiland-Jørgensen wrote: > >> > We're also working on adding a TXQ for (bufferable) management packets >> > - I wonder how that should interact here? Always be scheduled first? >> >> Ah, cool! It may be that it should be given priority, yeah. Presently, >> the multicast queue just rotates in the RR with the others, but is never >> throttled as it doesn't have an airtime measure (though perhaps it >> should)? But that might not be desirable for management frames, as >> presumable those need to go out as fast as possible? > > Good question. I guess the multicast should have an airtime measure, > but I don't think we want to do accounting on the management. That > really should be few frames, and we want them out ASAP in most cases. Yup, makes sense. >> Hmm, I seem to recall thinking about just putting the call to >> schedule_txq() into drv_wake_tx_queue; don't remember why I ended up >> dropping that; but will take another look at whether it makes sense to >> combine things. > > I was thinking the other way around - but that doesn't work since you'd > loop from the driver to itself. This way might work, I guess, hadn't > considered that. > > Might be better anyway though to make a new inline that does both, since > the drv_() calls usually really don't do much on their own (other than > checks, and in one case backward compatibility code, but still) ACK, I'll look into that. -Toke
