<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hello,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 9, 2019 at 6:03 PM Toke Høiland-Jørgensen <<a href="mailto:toke@redhat.com">toke@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Georgios Amanakis <<a href="mailto:gamanakis@gmail.com" target="_blank">gamanakis@gmail.com</a>> writes:<br>
<br>
> Dear List,<br>
><br>
> I made an effort to profile the performance of cake with perf in<br>
> openwrt. perf was run on a WRT1900ACS router while downloading<br>
> archlinux.iso via torrent in a LAN client. You can find the annotated<br>
> sch_cake.c in the attachment as well as a performance histogram of<br>
> sch_cake (percentages are relative to sch_cake). Hopefully people can<br>
> take a look at it, and see if there are performance concerns.<br>
<br>
Hmm, nothing immediately jumps out as low-hanging fruit to be harvested.<br>
It's not too surprising the 200+-line cake_dequeue() is where most time<br>
is spent, since that is where the bulk of the algorithm is implemented.<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
And, well, there's nothing in there that can obviously be removed unless<br>
we want to drop features. I guess one could try to make it possible to<br>
disable features at compile time; but that carries quite a bit of<br>
complexity with it (for one, it needs testing with the combinatorial<br>
explosion of possible configurations), so don't think it's realistic.<br>
The only exception *might* be a compile time option to turn off those<br>
stats that are not needed for the algorithm to run...<br></blockquote><div><br></div>The algorithm itself has probably been optimized over the years. It<br>might be a good idea to think of other ways to perform some<br>operations and simplify the algorithm. The code may not be that<br>slow on a high end CPU such as a Core i5 and anything faster.<br><br>The problem with the current implementation is that it's not able to<br>saturate a gigabit connection even on dual core ARM routers with<br>frequencies above 1.2 GHz. Routers for home users are probably going<br>to rely on hardware offloads to saturate gigabit connections for a<br>long time. This doesn't mean cake is poorly optimized or poorly<br>implemented. It's not a good fit for small embedded systems with small<br>CPU caches.<br><br>Different data structures might help improve performance.<br><br>This is why I've run a bunch of tests over the last few weeks. My<br>conclusion is that the current version of cake can't deal with more<br>than 100 mbps on ar71xx. mt7621 seems to go up to about 200 mbps.<br><br>I was thinking of a few things to try:<br>- disable some stats and profile<br>- lower the number of queues from 1024 to 256<br>- look into profiling to figure out what's causing cache misses<br>- disable some features and profile again<br>- set up a lab for all this testing<br><br>It's hard to find the time to do all of this. There's a lot to learn<br>in the process.<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-Toke<br>
_______________________________________________<br>
Cake mailing list<br>
<a href="mailto:Cake@lists.bufferbloat.net" target="_blank">Cake@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/cake" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/cake</a><br>
</blockquote></div></div></div></div>