[PATCH] ath10k: Make HTT fill size configurable

Michal Kazior michal.kazior at tieto.com
Wed Jan 14 01:22:46 PST 2015

On 13 January 2015 at 22:08, Sujith Manoharan <sujith at msujith.org> wrote:
> Kalle Valo wrote:
>> I'm not sure if I really like this path of having interfaces to
>> configure driver internals. I suspect that if we add this, we will have
>> even more later. It's a lot more documenting for us and more work to the
>> users to understand what parameters they should use. Also this means
>> that testing will be more challenging as people will use different
>> values and results won't be comparable.
>> Isn't there any other way to solve the problem? Like automatically
>> changing the value somehow (no idea how) or some other means?
> We are limiting performance by restricting the fill size. A user
> will just use the default, which is still the same and remains
> unchanged. But, having a way to adjust this based on the platform
> seems reasonable to me and I think trying to change this value dynamically
> is overkill.

We should just fix the tx/rx processing instead. The HTT throttling
limit was originally introduced to deal with watchdog issues we've
seen on AP135. Tasklets were starving system too much.

I've been playing around with threaded irqs in ath10k in my tree and
I've seen improvement with Rx. However Tx instead becomes broken in
the process and I'm yet to find a definite and final answer why that
is the case. My suspicion is that NAPI, which is used by the ethernet
driver, runs in tasklets and they aren't frequent enough to trigger
ksoftirqd so they starve the system. The current non-threaded irq
approach yields more tasklet schedules for Tx and hits ksoftirqd more
often making it nice on userspace. If that's the case I don't really
have an idea how to solve this now.


More information about the ath10k mailing list