All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Righi <righiandr@users.sourceforge.net>
To: Paul Menage <menage@google.com>
Cc: Naveen Gupta <ngupta@google.com>,
	LKML <linux-kernel@vger.kernel.org>,
	David Miller <davem@davemloft.net>
Subject: Re: [RFC] [PATCH] cgroup: limit network bandwidth
Date: Wed, 23 Jan 2008 18:48:13 +0100 (MET)	[thread overview]
Message-ID: <47977DDC.6000101@users.sourceforge.net> (raw)
In-Reply-To: <6599ad830801230859l298da3a7r208502993276c86b@mail.gmail.com>

Paul Menage wrote:
> On Jan 23, 2008 8:48 AM, Andrea Righi <righiandr@users.sourceforge.net> wrote:
>>> 1. Implementation of soft limits (limit on contention of resource)
>>>    gets harder
>> Why? do you mean implementing a grace time when the soft-limit is
>> exceeded? this could be done in cgroup_nl_throttle() introducing 3
>> additional attributes to struct netlimit (i.e. hard_limit,
>> last_time_exceeded grace_time) and perform something like:
>> ...
>>         if ((current_rate > hard_limit) ||
>>             time_after(jiffies, last_time_exceeded + grace_time))
>>                         schedule_timeout(sleep);
>> ...
> 
> He's talking about cases where we want the behaviour to be
> work-conserving, whilst still offering guarantees in the event of
> contention. e.g. cgroups A and B each get a 20% guarantee on the TX
> path if they need it, but anyone can use any otherwise-idle bandwidth.
> (This is relatively straightforward to set up from userspace with the
> standard Linux traffic control tools).

OK.

>> Yes, the integration with iptables (as Paul said), and traffic shaping
>> rules would be absolutely the right way(tm) in perspective. I was just
>> proposing a possible simple API to implement the limiting stuff.
> 
> But this issue (traffic control for cgroups) is too complex to be
> described by a simple API. Any simple API you choose to try to
> describe the limiting directly will be insufficient for a good number
> of the potential users. Better to just provide a (very simple) API to
> hook into the existing (complex) traffic control API and leave the
> tricky stuff to userspace, where anyone can construct arbitrarily
> complex queueing schemes with a shell script and a few calls to "tc".
> 
> Paul
> 

OK, thanks for the clarifications.

-Andrea

  reply	other threads:[~2008-01-23 17:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-23  9:09 [RFC] [PATCH] cgroup: limit network bandwidth Andrea Righi
2008-01-23  9:24 ` Balbir Singh
2008-01-23 16:48   ` Andrea Righi
2008-01-23 16:59     ` Paul Menage
2008-01-23 17:48       ` Andrea Righi [this message]
2008-01-23  9:54 ` Paul Menage

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=47977DDC.6000101@users.sourceforge.net \
    --to=righiandr@users.sourceforge.net \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=menage@google.com \
    --cc=ngupta@google.com \
    /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.