Kalle Valo <kvalo@xxxxxxxxxxxxxx> writes: > 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. What, other hidden bugs? Unpossible! :) Would it be possible to merge the partial solution (which is ready now, basically) and fix the slow path in a separate patch later? (Just spit-balling here; I'm still fairly new to this process. But I am concerned that we'll hit a catch-22 where we can't get wider testing before it's "ready" and we can't prove that it's "ready" until we've had wider testing...) -Toke
