[PATCH] ath10k: Make HTT fill size configurable

[Sujith Manoharan]

Michal Kazior wrote:
> 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.

Then the fill limit restriction is a workaround for AP135
and shouldn't be applicable for other platforms ?

> 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.

I haven't looked at the TX path in detail, but regarding RX, these
were the bottlenecks:

* RX batch indication.
* HTT fill level.
* netif_receive_skb() usage instead of netif_rx().

AFAIK, the internal driver schedules only one tasklet for a CE interrupt
and everything is done in that context, along with refilling HTT.
ath10k has several stages: ISR -> CE tasklet -> HTT tasklet -> Replenish tasklet.
The softirq count/load will definitely be high with so many tasklets ?

Sujith