Re: [PATCH v4] ath9k: Switch to using mac80211 intermediate software queues.

Kalle Valo [off-list ref] writes:

Toke H=C3=B8iland-J=C3=B8rgensen [off-list ref] writes:

quoted

This switches ath9k over to using the mac80211 intermediate software
queueing mechanism for data packets. It removes the queueing inside the
driver, except for the retry queue, and instead pulls from mac80211 when
a packet is needed. The retry queue is used to store a packet that was
pulled but can't be sent immediately.

The old code path in ath_tx_start that would queue packets has been
removed completely, as has the qlen limit tunables (since there's no
longer a queue in the driver to limit).

Based on Tim's original patch set, but reworked quite thoroughly.

Cc: Tim Shepard <redacted>
Cc: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk>
---
Changes since v3 (most due to Felix; thanks!):
  - Correctly notify mac80211 when there are packets in the retry queue
    on powersave start/stop.
  - Get rid of ath_tx_aggr_resume().
  - Some readability changes and additional WARN_ON/BUG_ON in
    appropriate places.

This is great work but due to the regressions I'm not sure if this
will be ready for 4.9. To get more testing time I wonder if we should
wait for 4.10? IMHO applying this in the end of the cycle is too risky
and we should try to maximise the time linux-next by applying this
just after -rc1 is released.

Thoughts?

Well, now that we understand what is causing the throughput regressions,
fixing them should be fairly straight forward (yeah, famous last words,
but still...). I already have a patch for the fast path and will go poke
at the slow path next. It'll probably require another workaround or two,
so I guess it won't be the architecturally clean ideal solution; but it
would make it possible to have something that works for 4.9 and then
iterate for a cleaner design for 4.10.

-Toke