Kalle Valo <kvalo@xxxxxxxxxxxxxx> writes: > Toke Høiland-Jørgensen <toke@xxxxxxx> writes: > >>>>> 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! :) > > Yeah, right ;) > >> Would it be possible to merge the partial solution (which is ready now, >> basically) and fix the slow path in a separate patch later? > > What do you mean with partial solution? You mean ath9k users would > suffer from regressions until they are fixed? We can't do that. > >> (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...) > > I understand your point, but I don't want to rush this to 4.9 and then > start getting lots of bug reports and eventually forced to revert it. If > we just found a new serious regression the chances are that there are > more lurking somewhere and this patch is just not ready yet. So, the changes to mac80211 that fixes the known regressions of this patch have gone in. Any chance of seeing this merged during the current merge window? :) -Toke
