[PATCH] ath10k: Make HTT fill size configurable

[Sujith Manoharan]

Michal Kazior wrote:
> If I were to narrow down I'd say all uniprocessors. AP135 is just an
> example where the problem easily occurs since it has an underpowered
> cpu for the task. Even a more powerful single-core system will get
> into trouble - all you need is a couple extra netfilter rules, nat,
> some running services or additional processing hardware (usb anyone?).

There are platforms which offload such network operations to the HW.
AP148 is an example.

> Apparently this isn't enough. Also, tasklets aren't subject to regular
> scheduling policies and they just steal time from other threads. This
> is important if you consider how much time a single tasklet can run -
> you can actually estimate this.
> 
> 800mbps is 100mbytes/s. Assume this is what host system can handle at 100% cpu.
> HTT Rx ring is 1000 frames long which is ~1.5mbyte of data (assuming
> 1500bytes for each packet).
> You eventually end up with cycles which drain entire htt rx ring and
> then replenish it if you push more traffic that host cpu can take.
> 100mbytes / 1.5mbytes = ~66runs/s which is ~15ms for each tasklet run.
> That's a lot. You might not get a chance to cycle through all the
> running processes to give them their timeslice for a few seconds..
> 
> If you starve userspace which runs a watchdog process you'll end up
> failing to poke the watchdog timer in kernel and you'll get a reboot.
> 
> I'm starting to think tasklets are plain evil for network drivers :P

Well, we need a way to lift the fill level restriction for platforms
that can afford a higher value, until the tx/rx engine in ath10k is
rewritten - and I don't want to carry an internal patch...

Sujith