linux-kernel - Re: [RFC] [PATCH] cgroup: limit network bandwidth

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <47977DDC.6000101@users.sourceforge.net>
Date:	Wed, 23 Jan 2008 18:48:13 +0100 (MET)
From:	Andrea Righi <righiandr@...rs.sourceforge.net>
To:	Paul Menage <menage@...gle.com>
Cc:	Naveen Gupta <ngupta@...gle.com>,
	LKML <linux-kernel@...r.kernel.org>,
	David Miller <davem@...emloft.net>
Subject: Re: [RFC] [PATCH] cgroup: limit network bandwidth

Paul Menage wrote:
> On Jan 23, 2008 8:48 AM, Andrea Righi <righiandr@...rs.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/