<div dir="ltr"><div dir="ltr">Hello,<br><br>These are some some random thoughts and notes related to some of my<br>experiments with cake and traffic shaping.<br><br>The performance issues observed on the cake setup seemed to be worth<br>another look. The mirred and ifb setup seemed to have lower performance<br>than expected.<br><br>This was easy enough to test by replacing cake with sfq on the ifb<br>interface. The setup had the same performance issues as the setup with<br>cake.<br><br>It's most likely not reasonable to expect cake to be able to shape at<br>1 gbps either if a setup with something with less complexity can't deal<br>with 300-400 mbps worth of MTU sized packets in the mirred and ifb<br>setup.<br><br>This set of experiments has determined me to consider alternative<br>options for ingress. A policer seems to be the right choice.<br><br>A policer which sets the ECN bit on ECT enabled flows could help. There<br>doesn't seem to be a documented way of doing this with tc actions &<br>filters. Would this be possible for IPv6 traffic? The ECN marking on<br>ECT enabled flows is the missing bit which would make this work for<br>IPv4. A pedit action may be useful if combined with a match on ECT.<br>It's something I haven't figured out yet.<br><br>Perhaps some tests with a simple flow blind marking policer would be<br>worth a shot.<br><br>Maybe it'd be worth to see other people's setups and even ISP type<br>setups to figure out what else to try.<br><br><br>Some of my other experiments included wifi ingress shaping. The upload<br>speed seemed capped at 3-8 mbps while wifi was shaped on ingress. This<br>appears to be a bug.<br>Shaping wifi at a rate which is lower than that of the link's total<br>bandwidth seems to be more difficult since we can't limit on ingress<br>based on the egress interface.</div></div>