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.
Hello, David.
On Mon, Jan 04, 2016 at 12:17:08PM -0700, David Ahern wrote:
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.
I don't have an answer for that but cgroup isn't a place to put such
stray configurations either. Please figure out where the
configuration belongs first. What you're proposing really isn't a
resource controller. There's no resource being distributed
hierarchically. It's just dumping configuration which hasn't found
its proper place into cgroup.
Thanks.
--
tejun
On 1/4/16 12:23 PM, Tejun Heo wrote:
I don't have an answer for that but cgroup isn't a place to put such
stray configurations either. Please figure out where the
configuration belongs first. What you're proposing really isn't a
resource controller. There's no resource being distributed
hierarchically. It's just dumping configuration which hasn't found
its proper place into cgroup.
cgroups have very nice properties that I want to leverage such as
parent-child inheritance and easy tracking which subsystem instance a
task belongs. This provides a great kernel foundation for building easy
to use management tools.
The documentation for cgroups does not restrict a controller to physical
resources but rather "it may be anything that wants to act on a group of
processes." That is exactly what I am doing here - I have a network
config that is applied to a group of processes similar to net_cls and
net_prio (but as I stated before those are orthogonal, independent
settings from the L3 domain).