Johannes Berg [off-list ref] writes:

On Wed, 2018-08-29 at 11:22 +0200, Toke H=C3=B8iland-J=C3=B8rgensen wrote:

quoted

quoted

We're also working on adding a TXQ for (bufferable) management packets
- I wonder how that should interact here? Always be scheduled first?

=20
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.

quoted

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