All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Borkmann <dborkman@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: pablo@netfilter.org, netfilter-devel@vger.kernel.org,
	netdev@vger.kernel.org, cgroups@vger.kernel.org
Subject: Re: [PATCH nf-next] netfilter: xtables: lightweight process control group matching
Date: Wed, 09 Oct 2013 21:12:49 +0200	[thread overview]
Message-ID: <5255AAB1.5000802@redhat.com> (raw)
In-Reply-To: <20131009170409.GH22495@htj.dyndns.org>

On 10/09/2013 07:04 PM, Tejun Heo wrote:
> Hello,
>
> On Tue, Oct 08, 2013 at 10:05:02AM +0200, Daniel Borkmann wrote:
>> Could you elaborate on "Wouldn't it be more logical to implement netfilter
>> rule to match the target cgroup paths?". I don't think (or hope) you mean
>> some string comparison on the dentry path here? :) With our proposal, we
>> have in the network stack's critical path only the following code that is
>> being executed here to match the cgroup ...
>
> Comparing path each time obviously doesn't make sense but you can
> determine the cgroup on config and hold onto the pointer while the
> rule exists.
>
>> ... where ``info->id == skb->sk->sk_cgrp_fwid'' is the actual work, so very
>> lightweight, which is good for high loads (1Gbit/s, 10Gbit/s and beyond), of
>> course. Also, it would be intuitive for admins familiar with other subsystems
>> to just set up and use these cgroup ids in iptabels. I'm not yet quite sure
>> how your suggestion would look like, so you would need to setup some "dummy"
>> subgroups first just to have a path that you can match on?
>
> Currently, it's tricky because we have multiple hierarchies to
> consider and there isn't an efficient way to map from task to cgroup
> on a specific hierarchy.  I'm not sure whether we should add another
> mapping table in css_set or just allow using path matching on the
> unified hierarchy.  The latter should be cleaner and easier but more
> restrictive.
>
> Anyways, it isn't manageable in the long term to keep adding
> controllers simply to tag tasks differently.  If we want to do this,
> let's please work on a way to match a task's cgroup affiliation
> efficiently.

Agreed, let us solve that first, and then I go back to the netfilter module
to bring netfilter and cgroups together.

Thanks,

Daniel

  reply	other threads:[~2013-10-09 19:12 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-04 18:20 [PATCH nf-next] netfilter: xtables: lightweight process control group matching Daniel Borkmann
2013-10-07  3:07 ` Gao feng
2013-10-07  9:17   ` Daniel Borkmann
     [not found]     ` <52527C3E.1060004-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-10-07  9:42       ` Gao feng
2013-10-07 16:46 ` Tejun Heo
2013-10-08  8:05   ` Daniel Borkmann
     [not found]     ` <5253BCAE.5060409-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-10-09 17:04       ` Tejun Heo
2013-10-09 19:12         ` Daniel Borkmann [this message]
     [not found]         ` <20131009170409.GH22495-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>
2013-10-10 21:55           ` Daniel Borkmann
     [not found] ` <1380910855-12325-1-git-send-email-dborkman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-10-18 23:21   ` Eric W. Biederman
     [not found]     ` <87li1qp3l8.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-10-19  7:16       ` Daniel Borkmann
2013-10-21 15:09         ` Daniel Wagner
     [not found]           ` <526543A2.2040901-kQCPcA+X3s7YtjvyW6yDsg@public.gmane.org>
2013-10-21 15:48             ` Daniel Borkmann
2013-10-22  7:15               ` Ni, Xun
2013-10-22  7:42                 ` Daniel Borkmann
2013-10-22  7:45                 ` Daniel Wagner
     [not found]               ` <52654CE6.7030706-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-10-22  7:36                 ` Daniel Wagner
     [not found] <cover.1382101225.git.dborkman@redhat.com>
2013-10-18 13:28 ` Daniel Borkmann
     [not found]   ` <ee0fb538d6e43e23d0488d3edd741de9c4589fb1.1382101225.git.dborkman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-11-05 13:03     ` Daniel Borkmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5255AAB1.5000802@redhat.com \
    --to=dborkman@redhat.com \
    --cc=cgroups@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.