From mboxrd@z Thu Jan 1 00:00:00 1970 From: Glauber Costa Subject: Re: [RFC] per-containers tcp buffer limitation Date: Thu, 25 Aug 2011 15:11:37 -0300 Message-ID: <4E569059.1020606@parallels.com> References: <4E558137.5020900@parallels.com> <4E55A55B.8090608@parallels.com> <20110825104956.41c4b60e.kamezawa.hiroyu@jp.fujitsu.com> <4E56464B.4070304@monom.org> <4E5664B5.6000806@genband.com> <20110825084415.3c3094e8@nehalam.ftrdhcpuser.net> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20110825084415.3c3094e8@nehalam.ftrdhcpuser.net> Sender: netdev-owner@vger.kernel.org To: Stephen Hemminger Cc: Chris Friesen , Daniel Wagner , "Eric W. Biederman" , KAMEZAWA Hiroyuki , Linux Containers , netdev@vger.kernel.org, David Miller , Pavel Emelyanov List-Id: containers.vger.kernel.org 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! From mboxrd@z Thu Jan 1 00:00:00 1970 From: Glauber Costa Subject: Re: [RFC] per-containers tcp buffer limitation Date: Thu, 25 Aug 2011 15:11:37 -0300 Message-ID: <4E569059.1020606@parallels.com> References: <4E558137.5020900@parallels.com> <4E55A55B.8090608@parallels.com> <20110825104956.41c4b60e.kamezawa.hiroyu@jp.fujitsu.com> <4E56464B.4070304@monom.org> <4E5664B5.6000806@genband.com> <20110825084415.3c3094e8@nehalam.ftrdhcpuser.net> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: Chris Friesen , Daniel Wagner , "Eric W. Biederman" , KAMEZAWA Hiroyuki , Linux Containers , , David Miller , Pavel Emelyanov To: Stephen Hemminger Return-path: Received: from mx2.parallels.com ([64.131.90.16]:37824 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755124Ab1HYSME (ORCPT ); Thu, 25 Aug 2011 14:12:04 -0400 In-Reply-To: <20110825084415.3c3094e8@nehalam.ftrdhcpuser.net> Sender: netdev-owner@vger.kernel.org List-ID: 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!