Messages in this thread | | | Date | Thu, 24 Jul 2008 21:18:21 -0400 | From | "Paul Menage" <> | Subject | Re: [PATCH] Traffic control cgroups subsystem |
| |
On Thu, Jul 24, 2008 at 7:45 PM, Thomas Graf <tgraf@suug.ch> wrote: > > It might have been easier to simply write a classifier which maps pids > to classes. The interface could be as simple as two nested attributes, > ADD_MAPS, REMOVE_MAPS which both take lists of pid->class mappings to > either add or remove from the classifier.
You mean as processes fork/exit or move between cgroups you have to update the pid->class mappings in the kernel's filter? That sounds way too fragile to me.
> > I have been working on this over the past 2 weeks, it includes the > classifier as just stated, a cgroup module which sends notifications > about events
What types of events? We discussed how to send cgroup notifications to userspace in the containers mini-summit on Tuesday. Netlink was one of the options discussed, but suffers from the problem that netlink sockets are tied to a particular network namespaces. The solution that seemed most favoured was to have pollable cgroup control files that represent events (and optionally support event data via a fifo).
> as netlink messages and a daemon which creates qdiscs, > classes and filters on the fly according to the configured distribution.
> It works both ingress (with some tricks) and egress. > > IMHO, there is no point in a cgroup interface if the user has to create > qdiscs, classes and filters manually anyway. >
The user can use whatever middleware they want (e.g. your daemon, libcg, etc) to set up qdiscs and classes. I don't think that requiring any particular userspace implementation is the right way to go. The point of this patch was to provide a minimal way to tag sockets/packets as belonging to a particular cgroup, in order to make use of the existing traffic controll APIs.
Paul
| |