Johannes Berg [off-list ref] writes:

On Mon, 2018-09-10 at 12:57 +0200, Toke H=C3=B8iland-J=C3=B8rgensen wrote:

quoted

Johannes Berg [off-list ref] writes:
=20

quoted

On Sat, 2018-09-08 at 00:22 +0200, Toke H=C3=B8iland-J=C3=B8rgensen wr=

ote:

quoted

quoted

quoted

=20
Usage of the new API is optional, so drivers can be ported one at a =

time.

quoted

quoted

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

=20
Could you elaborate a bit more on how the hwq/txq stuff works in iwl?

I can try.

quoted

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