Thread (51 messages) 51 messages, 7 authors, 2016-12-15

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

From: Arend van Spriel <arend.vanspriel@broadcom.com>
Date: 2016-08-23 08:52:55


On 23-08-16 08:59, Kalle Valo wrote:
Toke Høiland-Jørgensen [off-list ref] writes:
quoted
quoted
quoted
quoted
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 ;)
quoted
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.
quoted
(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...)
So could the wider testing be accomplished by working on a branch in the
wireless-testing repo and make its availability known on wireless-list,
ath?k-list, LWN or whatever.

Regards,
Arend
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help