Kalle Valo <kvalo@xxxxxxxxxxxxxx> writes: > Toke Høiland-Jørgensen <toke@xxxxxxx> writes: > >> 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 <shep@xxxxxxxxxxxx> >> Cc: Felix Fietkau <nbd@xxxxxxxx> >> Signed-off-by: Toke Høiland-Jørgensen <toke@xxxxxxx> >> --- >> 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
