[Make-wifi-fast] [PATCH RFC v3 1/4] mac80211: Add TXQ scheduling API

[Toke Høiland-Jørgensen]

Johannes Berg <johannes at sipsolutions.net> writes:

> On Mon, 2018-09-10 at 12:57 +0200, Toke Høiland-Jørgensen wrote:
>> Johannes Berg <johannes at sipsolutions.net> writes:
>> 
>> > On Sat, 2018-09-08 at 00:22 +0200, Toke Høiland-Jørgensen wrote:
>> > > 
>> > > Usage of the new API is optional, so drivers can be ported one at a time.
>> > 
>> > With the 1:1 hardware queue/txq mapping in iwlwifi (we're close to
>> > getting that patch in, though now the Jewish holidays mean a delay),
>> > I'm not sure we'd be able to do this at all in iwlwifi. So this may
>> > not be a case of porting one at a time until we can get rid of it ...
>> 
>> Could you elaborate a bit more on how the hwq/txq stuff works in iwl?
>
> I can try.
>
>> Does the driver just hand off a TXQ to the hardware on wake_txq(), which
>> is then scheduled by the hardware after that? Or how does the mapping to
>> hwqs work, and how is the hardware notified that there are still packets
>> queued / that new packets have arrived for an already mapped txq?
>
> Basically, we use the TXQ driver data to do this. On initialization, we
> set all TXQs to have no hardware queue mapped. Then, when the first wake
> happens for this TXQ, we allocate a hardware queue for this RA/TID.
>
> From then on, right now we basically just try to refill the hardware
> queue from the TXQ whenever the hardware releases frames from that
> queue. If there are none, we fall back to putting them on the hardware
> queue from the wake signal.

OK. So if the TXQ is ineligible to dequeue packets, but still have them
queued, there would need to be a signal (such as wake_txq()) when it
becomes eligible again, right?

-Toke