Re: [PATCH v3 0/6] cgroup cls & netprio 'cleanups'

On Tue, Aug 14, 2012 at 03:46:49PM +0200, Daniel Wagner wrote:

Hi Neil,

On 14.08.2012 15:30, Neil Horman wrote:

quoted

On Tue, Aug 14, 2012 at 03:25:50PM +0200, Daniel Wagner wrote:

quoted

On 14.08.2012 15:10, Neil Horman wrote:

quoted

On Tue, Aug 14, 2012 at 03:02:16PM +0200, Daniel Wagner wrote:

quoted

From: Daniel Wagner <redacted>

Hi,

Sorry for the delay on updating this series. The usual
excuse apply here.

I saw that John is busy improving net_prio so I took the
liberty to port his changes to net_cls (#1-3). Patch #3 will
collide with John's unapplied patches. I am happy
to rebase this series if needed.

Patch #4 and #5 improve the readability with using
IS_MODULE/BUILTIN macros. This patches prepare the last
patch.

Patch #6 removes support for assigning subsystem IDs during
runtime. As it turns out this is not really needed. By doing
so we are able to free some unused memory.

The patches are against net-next.

cheers,
daniel

These aren't so much 'cleanups' as feature enhancements and fixes for the first
pass of those enhancements (at least in the case of the net_prio cgroup).

Sorry about that. I wanted to keep the series title, so that someone
looking up older versions find it.

That makes sense, but it would be best until we acked the the version going into
net_prio, otherwise we maybe tracking regressions in two places rather than one.

I agree, let's wait until net_prio gets stable.
 

quoted

quoted

quoted

I've nothing against them, but since we're still going through some churn on the
net_prio variant, it may be best to wait until thats settled before moving them
over to net_cls.

Sure, I can update this series when the net_prio controller changes
have settled down.

Thank you, I think thats a good idea.

quoted

I just wonder if it wouldn't make sense to merge them together.
Obviously, that will break the user space which is not a good thing
but having a controller per socket option is not good either.

This has been discussed (although perhaps not on list) before.  I don't think
we're going to see lots of cgroups for socket options.  most of them have proc
tunables, priroity and classification dont.

Well, I'll would like to able to set SO_MARK via a controller [1][2]. The use
case is that I'd like to set the routing table per application. As it turns
out the kernel has almost all bits and pieces to get this working. The only
missing thing is setting SO_MARK without touching the application. For which
the net cgroup controllers seem to be the perfect match.

Ok, I stand corrected, there are other things that might be good for using with
cgroups in the networking space.

quoted

We could merge the two controllers,
but as you said it breaks users space which is a non-starter.  It also doesn't
really buy us anything, as people want to be able to set priority and
classification independently, so we either use two controllers, or one
controller with twice as many cgroup instances (one for each combination of
priroity/class that an admin wants).

Okay, I see your point. What is your standpoint concerning SO_MARK? Following
your logic, we would need another controller for this which is what I rather
have avoided. But I am more than happy to send patches for this :)

Others may well have differing opinions, but my feeling is separate controllers
for separate functions.  As noted, while you could merge all the controllers, it
doesn't buy you much, and convolutes the meaning of a particular cgroup instance
(i.e. with a merged controller, a given cgroup instance owuld enforce
clasification A, priority B and mark value C, while another could enforce class
D priority B and mark C.  With separate controllers, admins can independently
select which class/priority and mark value to apply orthogonally.

So I'd vote for separate controllers.

quoted

I'll ping you when the net_prio stuff settles out.

Great, thanks.

cheers,
daniel

[1] http://lists.connman.net/pipermail/connman/2012-August/010716.html
[2] http://lists.connman.net/pipermail/connman/2012-August/010715.html

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html