On 1/4/16 11:59 AM, Tejun Heo wrote:

Hello, David.

On Mon, Jan 04, 2016 at 11:53:55AM -0700, David Ahern wrote:

quoted

On 1/4/16 10:58 AM, Tejun Heo wrote:

quoted

Please don't create any new controller whose sole purpose is
identifying group membership.  Please take a look at how libxt_cgroup
handles identification w/o creating a new controller.

  http://lkml.kernel.org/g/1449527935-27056-1-git-send-email-tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org

This controller applies a cgroup specific setting to tasks associated with
an instance (similar to cpuset restricting tasks to specifics CPUs), so it
is more than just identifying membership.

Any identification can be mapped back and forth to setting configs to
a set of tasks.  That doesn't change the fact that all the controller
is doing is identifying cgroup membership and the proposed controller
shares exatly the same problems as netprio or netcls controllers.

quoted

I looked at the commits referenced above and net/netfilter/xt_cgroup.c code
in particular and I don't see how it applies to this use case. Can you
elaborate?

Match cgroup membership in whatever subsystem that cares about it and
apply the policy there.

None of the existing subsystems are relevant for configuring an L3 
networking domain, and it does not make sense to tie net_cls and 
net_prio to an L3 domain.