Hello,<br><br>Ok. Thank you very much for your advice! We will try to implement these two features: provisioning and limitation.<br><br>Ana & Irina.<br><br><div class="gmail_quote">On Sat, Mar 19, 2011 at 11:52 PM, Daniel Lezcano <span dir="ltr"><<a href="mailto:daniel.lezcano@free.fr">daniel.lezcano@free.fr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div></div><div class="h5">On 03/18/2011 06:40 PM, Farcasi Ana-Maria wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hello,<br>
<br>
As mentioned in our previous email, we were having issues getting bandwidth<br>
limitation working on cgroup ( with net_cls ) and tc. We've been running<br>
various tests and scenarios but found no way to enable proper limitation.<br>
Throughout our testing we've created a virtual machine running a 2.6.35<br>
kernel where the limitation was indeed working.<br>
<br>
We've browsed recent commits in the Linux-2.6 kernel source code and<br>
discovered that ever since version 2.6.35 (actually ever since this<br>
commit[1] was integrated), there is a change in getting the packet classid -<br>
the classid is stored and read as a member of a struct sock. As this is also<br>
used by LXC, it means that ever since 2.6.35, bandwidth limitation using tc<br>
is working for cgroups.<br>
<br>
In order to prove this, we've compiled the latest 2.6.34 and 2.6.35 kernels<br>
(2.6.34.8 and 2.6.35.11). We've used tc, cgroup (net_cls) and iperf to test<br>
this.<br>
<br>
On the latter version ( 2.6.35.11 ) the limitation is working accordingly,<br>
while on the former ( 2.6.34.8 ) the limitation is not working at all. We<br>
believe the above mentioned commit[1] is responsible for solving this issue<br>
and post-2.6.35 kernels should have no problems using cgroup-based bandwidth<br>
limitation (for example, within LXC).<br>
<br>
We were thinking whether it would be a good idea to integrate an option for<br>
bandwidth limitation into an LXC container configuration file (such as<br>
lxc.network.bwlimit). This would allow a rapid setup of an LXC container and<br>
network limitation. This could, of course, be set up using tc (it would take<br>
a bit more effort, though). What do you think?<br>
</blockquote>
<br>
<br></div></div>
Hi Irina and Ana,<br>
<br>
Thanks for investigating this, it is very useful.<br>
<br>
Adding the setup to lxc is a good idea and I will be happy to merge upstream your modifications to take into account the bandwidth limitations.<br>
<br>
As far as I remember the bandwidth limitations is for download and upload no ? If it is the case, I would recommend to use the options:<br>
<br>
lxc.network.bandwidth.download = value<br>
lxc.network.bandwidth.upload = value<br>
<br>
I thought another feature would be interesting, the network provisioning. I don't if it is supported by the kernel (I don't think so) but if we can assign for example 1GB of download/upload to the container and when it is reached the network become stuck until we add more provisioning, that could be very useful. What do you think ?<br>

<br>
Thanks<br>
  -- Daniel<br>
<br>
 <javascript:void(0);><br>
</blockquote></div><br>