From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754900AbYIJXiV (ORCPT ); Wed, 10 Sep 2008 19:38:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751989AbYIJXiI (ORCPT ); Wed, 10 Sep 2008 19:38:08 -0400 Received: from smtp-out.google.com ([216.239.33.17]:7420 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751986AbYIJXiH (ORCPT ); Wed, 10 Sep 2008 19:38:07 -0400 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=vZCn84bJzo2vu9X9Y6HSbc84kHU16FKVdC/5FLMeB+pQ0UkogYz5tCOGo4tpnmPOz Zf0RX2DbsmjoDagoEsQAg== Message-ID: <166fe7950809101637o1bf22869g4939707a35a3c93b@mail.gmail.com> Date: Wed, 10 Sep 2008 16:37:57 -0700 From: "Ranjit Manomohan" To: "Thomas Graf" Subject: Re: [PATCH 0/2] Traffic control cgroups subsystem Cc: "David Miller" , kaber@trash.net, akpm@linux-foundation.org, lizf@cn.fujitsu.com, menage@google.com, linux-kernel@vger.kernel.org, netdev@vger.kernel.org In-Reply-To: <20080910221206.GI20815@postel.suug.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080910.132251.73509521.davem@davemloft.net> <166fe7950809101344l7a5e2b7pfba8b2a7c03814a1@mail.gmail.com> <20080910221206.GI20815@postel.suug.ch> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 10, 2008 at 3:12 PM, Thomas Graf wrote: > * Ranjit Manomohan 2008-09-10 13:44 >> On Wed, Sep 10, 2008 at 1:22 PM, David Miller wrote: >> > >> > I definitely prefer Thomas Graf's work, this stuff is very ugly >> > and way overengineered. >> > >> >> Could you be more specific? Thomas' work is almost identical to this >> (except that he does not store the cgroup id into the socket which is >> a trivial change which has downsides which I have pointed out). >> >> Additionally this approach has only minor modifications to the core >> networking stack. What portions do you consider ugly and over >> engineered and what alternative implementations would you prefer? >> Please see the follow up I have sent to Thomas' proposal about why we >> need this design approach to handle the inbound case. > > WRT the inbound case, after some experiments I decided to dismiss the > ingress case at all and stick to something as simple as possible for > egress. The reason for this is that it is a very expensive operation > to associate a packet with a task on classifier level. Taking this > cost, it does not add up with the very limited capabilities of ingress > shaping. Ingress shaping is best effort at best. It works fairly well > with a very limited number of bulk data streams but usualy fails > miserably in common congestion situations where a cgroup classifier > would be useful. Could you elaborate on the failure cases? We have found this to be useful in practice to prevent applications from reading large amounts of data off the network so it would be nice if it were supported. -Thanks, Ranjit > >> I'd be ok if you accepted either change since we just want a standard >> kernel mechanism to do this. > > Agreed. I think your approach is very reasonable but considering the > reasons I've given above and in the other thread I found it could be done > in a more simple and direct way. >