Hi Ed, On 9/16/2020 7:40 AM, Ed W wrote: > Hi, I'm getting great success with the "CAKE" qdisc on linux. It appears > to use same or lower CPU than say HFSC and seems to work well with a > fairly wide variety of network speeds without significant tuning (I'm > using it between 330Mbit/s down to 100Kbit/s) > > The needs of cake to support it aren't that great. Basically it has a > few tunables to the basic qdisc that mostly affect overhead > computations, plus some options for bandwidth. The overhead computations > are quite similar to some of the existing Qdiscs params, but there are > some new options. Finally the classes are fixed and not editable, other > than there is a qdisc option to choose from one of several options for > the classes (3, 4 or 8 classes) > > After that I *think* directing traffic to classes is just the same as > for other qdisc types. I'm marking up connmarks and applying those to > incoming packets in the mangle table in order to be able to mark in the > IFB device. However, I suspect I can ditch my custom support for this > with latest shorewall? > > One other feature which is useful for cake is that it can read the > fwmark on it's own. You give it a mask and this is read from the packet > and interpreted as the class to apply to the packet for queuing/policing. > > Broadly I've found it very effective and low CPU. Quantum seems to be > automatically set and other than I disagree with it's default mapping of > TCP DSCP priorities to internal queues (which I've changed as a personal > kernel patch) it works really well right out of the box > > I also use it in conjunction with iptables NDPI filter which can > automatically apply a firewall mark to traffic which is of a specific > application type. So I simply maintain a simple text file which maps say > "zoom" to a certain packet mark or "bittorrent" to another, etc. Very > simple and takes care of 90% of my marking needs (albeit not the first > few packets of any connection) > > > I wanted to add support for cake to shorewall, but a little poking in > the code path shows that it's a bit hairy to add another qdisc type. I > think I need a bit of support on the best way to go ahead... There are > large sections of code protected with IF statements. My thought was to > look to break this up a little and move to separate modules for the > various qdisc types?
I agree that the structure of the current code makes it difficult to add a new qdisc. > > I dunno. I confess I lost my inertia on this a month back and so I'm > mentioning more that I would be willing to sponsor some work here if > someone wanted to pick it up? > I'll take a look at restructuring the code for 5.2.9 with the goal of extensibility. -Tom -- Tom Eastep \ Q: What do you get when you cross a mobster Shoreline, \ with an international standard? Washington, USA \ A: Someone who makes you an offer you http://shorewall.org \ can't understand \________________________________________
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
