login
Login
/
Register
Search
Forums
News
Blogs
Features
Site
Home
»
Mailing list archives
»
linux-kernel
»
2008
»
January
»
23
Re: [RFC] [PATCH] cgroup: limit network bandwidth
view
thread
!MAILaRCHIVE_VOTE_RePLACE
Previous message: [
thread
] [
date
] [
author
]
Next message: [thread] [
date
] [
author
]
[view in full thread]
From:
Andrea Righi <righiandr@...>
To: Paul Menage <menage@...>
Cc: Naveen Gupta <ngupta@...>, LKML <linux-kernel@...>, David Miller <davem@...>
Subject:
Re: [RFC] [PATCH] cgroup: limit network bandwidth
Date: Wednesday, January 23, 2008 - 1:48 pm
Paul Menage wrote:
quoted text
> 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.
quoted text
>> 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 --
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to
majordomo@vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
http://www.tux.org/lkml/
Previous message: [
thread
] [
date
] [
author
]
Next message: [thread] [
date
] [
author
]
Messages in current thread:
[RFC] [PATCH] cgroup: limit network bandwidth
, Andrea Righi
, (Wed Jan 23, 5:09 am)
Re: [RFC] [PATCH] cgroup: limit network bandwidth
, Paul Menage
, (Wed Jan 23, 5:54 am)
Re: [RFC] [PATCH] cgroup: limit network bandwidth
, Balbir Singh
, (Wed Jan 23, 5:24 am)
Re: [RFC] [PATCH] cgroup: limit network bandwidth
, Andrea Righi
, (Wed Jan 23, 12:48 pm)
Re: [RFC] [PATCH] cgroup: limit network bandwidth
, Paul Menage
, (Wed Jan 23, 12:59 pm)
Re: [RFC] [PATCH] cgroup: limit network bandwidth
, Andrea Righi
, (Wed Jan 23, 1:48 pm)
Navigation
Create content
Mailing list archives
Recent posts
Popular discussions
linux-kernel
:
Greg Kroah-Hartman
[PATCH 002/196] Chinese: rephrase English introduction in HOWTO
Tarkan Erimer
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Amit K. Arora
[RFC] Heads up on sys_fallocate()
Linus Torvalds
Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes g...
git
:
linux-netdev
:
David Miller
[GIT]: Networking
Jarek Poplawski
Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock().
Gerrit Renker
[PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side)
Ray Lee
Re: [BUG] New Kernel Bugs
openbsd-misc
:
Colocation donated by:
Who's online
There are currently
1 user
and
567 guests
online.
Online users
hotpicks
Syndicate