Control groups, part 5: The cgroup hierarchy [LWN.net]

Control groups, part 5: The cgroup hierarchy

Posted Jul 31, 2014 22:56 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
In reply to: Control groups, part 5: The cgroup hierarchy by neilbrown
Parent article: Control groups, part 5: The cgroup hierarchy

Probably a bit of both. An interface with integer handles is not easy to use - nice textual names instead of major:minor pairs would have helped a lot. Then there's the problem with error messages (they are opaque) and discoverability of settings.

And conceptually I never understood why qdisc is separate from iptables.

to post comments

Control groups, part 5: The cgroup hierarchy

Posted Aug 6, 2014 7:05 UTC (Wed) by kleptog (subscriber, #1183) [Link] (1 responses)

As an interface to the kernel integer handles are fine, see file descriptors for example.

But as a method of control by humans they are horrid. What was (is?) really needed is some kind of declarative language where you could describe what you want to achieve and then some compiler would compile that into a tc commands for you.

Control groups, part 5: The cgroup hierarchy

Posted Jan 22, 2015 1:46 UTC (Thu) by ras (subscriber, #33059) [Link]

These is (or was) such a thing. It's called tcng. Sadly it's been unmaintained for a over a decade now.

A for the earlier comment "we should just use iptables", the reason hard core tc user doesn't want that is speed. Yes, iptables is easy to use, but it's naturally linear. A packet going through 20 or 30 rules is not at all uncommon. Yes, you can code your rules so that doesn't happen, but then it's not so easy to use. With tc's u32 on the other hand you don't have a choice. Every rule is just a 32 bit load, mask and compare, and possibly a jump via a hash table. You tend to use hash tables, so the number of rules evaluated is stuff all. As a consequence it runs like a scalded cat. There is some syntatic sugar, but it has the effect of turning what is essentially a machine language into assembler language.

But yes, speed concerns aside using one filtering language every place a filter is used seems like it would be a utopia compared to what we have now. And there are a lot of such places - ip route, ip rule, iptables, and u32 spring to mind. But if you are going to do that speed is of the absolute essence. A declarative language that is easily compiled and optimised into something like a u32 virtual machine seems like it could work.

I had hoped nftables give us an interface like that, but as far as I can tell it doesn't quite get there. It's compiled and all, but it is still encourages the user write a set of rules that are executed linearly. That makes it hard to optimise it to the same extent a hand u32 filter would be.