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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
