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