On 13 January 2015 at 22:08, Sujith Manoharan <sujith@xxxxxxxxxxx> 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. Michał -- 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
