[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E569059.1020606@parallels.com>
Date: Thu, 25 Aug 2011 15:11:37 -0300
From: Glauber Costa <glommer@...allels.com>
To: Stephen Hemminger <shemminger@...tta.com>
CC: Chris Friesen <chris.friesen@...band.com>,
Daniel Wagner <wagi@...om.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
Linux Containers <containers@...ts.osdl.org>,
<netdev@...r.kernel.org>, David Miller <davem@...emloft.net>,
Pavel Emelyanov <xemul@...allels.com>
Subject: Re: [RFC] per-containers tcp buffer limitation
On 08/25/2011 12:44 PM, Stephen Hemminger wrote:
> You seem to have forgotten the work of your forefathers. When appealing
> to history you must understand it first.
>
> What about using netfilter (with extensions)? We already have iptables
> module to match on uid or gid. It wouldn't be hard to extend this to
> other bits of meta data like originating and target containers.
>
> You could also use this to restrict access to ports and hosts on
> a per container basis.
>
Hello Stephen,
I am pretty sure netfilter can provide us with amazing functionality
that will help our containers implementation a lot.
I don't think, however, that memory limitation belongs in there. First
of all, IIRC, we are not dropping packets, re-routing, dealing with any
low level characteristic, etc. We're just controlling buffer size. This
seems orthogonal to the work of netfilter.
Think for instance, in the soft limit: When we hit it, we enter a memory
pressure scenario. How would netfilter handle that?
So I guess cgroup is still better suited for this very specific task we
have in mind here. For most of the others, I have no doubt that
netfilter would come handy.
Thanks for your time!
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists