Toke Høiland-Jørgensen <toke@xxxxxxx> writes: > 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. But if we try to rush this to 4.9 it won't be in linux-next for long. We are now in -rc3 and let's say that the patches are ready to apply in two weeks. That would leave us only two weeks of -next time before the merge window, which I think is not enough for a controversial patch like this one. There might be other bugs lurking which haven't been found yet. -- Kalle Valo
