Re: [PATCH 0/2] Traffic control cgroups subsystem

Re: [PATCH 0/2] Traffic control cgroups subsystem

[김재열]

>Incorporated fixes suggested by Li Zefan.
>
>Please consider for net-next-2.6.
>
>This patch provides a simple resource controller (cgroup_tc) based on 
>the cgroups infrastructure to manage network traffic. The cgroup_tc 
>resource controller can be used to schedule and shape traffic belonging 
>to the task(s) in a particular cgroup.
>
>The implementation consists of two parts:
>
>1) A resource controller (cgroup_tc) that is used to associate packets from
>   a particular task belonging to a cgroup with a traffic control class id (
>   tc_classid). This tc_classid is propagated to all sockets created by tasks
>   in the cgroup and will be used for classifying packets at the link layer.
>
>2) A new traffic control classifier (cls_cgroup) that can classify packets
>   based on the tc_classid field in the socket to specific destination classes.
>
>An example of the use of this resource controller would be to limit the 
>traffic from all tasks from a file_server cgroup to 100Mbps. We could 
>achieve this by doing:
>
># make a cgroup of file transfer processes and assign it a arbitrary 
>unique # classid of 0x1234 - this will be used later to direct packets.
>mkdir -p /dev/cgroup
>mount -t cgroup tc -otc /dev/cgroup
>mkdir /dev/cgroup/file_transfer
>echo 0x1234 > /dev/cgroup/file_transfer/tc.classid
>echo $PID_OF_FILE_XFER_PROCESS > /dev/cgroup/file_transfer/tasks
>
># Now create a HTB class that rate limits traffic to 100mbits and 
>attach # a filter to direct all traffic from cgroup file_transfer to this new class.
>tc qdisc add dev eth0 root handle 1: htb tc class add dev eth0 parent 
>1: classid 1:10 htb rate 100mbit ceil 100mbit tc filter add dev eth0 
>parent 1: handle 800 protocol ip prio 1 cgroup value 0x1234 classid 
>1:10
>
>Signed-off-by: Ranjit Manomohan <ranjitm <at> google.com>
>

I installed your patch to kernel-2.6.27-rc7 with some hunkles but without failes.
After compiling the kernel, I run the command which you wrote above. Most of all commands successfully are run except the last command " tc filter add dev eth0 parent 1: handle 800 protocol ip prio 1 cgroup value 0x1234 classid 1:10"

After that, I received this messages
"Unknown filter "cgroup", hence option "value" is unparsable"

So I operated this command with "strace", then below messages returned.
...
socket(PF_NETLINK, SOCK_RAW, 0)         = 3
setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0 setsockopt(3, SOL_SOCKET, SO_RCVBUF, [32768], 4) = 0 bind(3, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0 getsockname(3, {sa_family=AF_NETLINK, pid=5452, groups=00000000}, [12]) = 0
time(NULL)                              = 1222389948
open("/usr/lib/tc/f_cgroup.so", O_RDONLY) = -1 ENOENT (No such file or directory) write(2, "Unknown filter \"cgroup\", hence o"..., 60Unknown filter "cgroup", hence option "value" is unparsable
) = 60
close(3)                                = 0
exit_group(1)                           = ?

This messages told me tc couldn’t find "f_cgroup.so" library in my system.
With this message, I thought that we need a modified "tc" command file to recognize the new filter, cgroup.

And I saw the line in your patch below
">Please consider for net-next-2.6."
What's the meaning of the line?
I wonder if I have to adopt another patch for net-netxt-2.6 before adopting this patch?

You didn't mentioned base kernel for this patch.
I am willing to know the base kernel version and why you didn't mention.

I've worked couple of days for resolving this problem. But I couldn't find the proper answer yet.

I'd really thank you if you help me.


To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo <at> vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] Traffic control cgroups subsystem

[Chen Zumeng]

김재열 wrote:
>> Incorporated fixes suggested by Li Zefan.
>>
>> Please consider for net-next-2.6.
>>
>> This patch provides a simple resource controller (cgroup_tc) based on 
>> the cgroups infrastructure to manage network traffic. The cgroup_tc 
>> resource controller can be used to schedule and shape traffic belonging 
>> to the task(s) in a particular cgroup.
>>
>> The implementation consists of two parts:
>>
>> 1) A resource controller (cgroup_tc) that is used to associate packets from
>>   a particular task belonging to a cgroup with a traffic control class id (
>>   tc_classid). This tc_classid is propagated to all sockets created by tasks
>>   in the cgroup and will be used for classifying packets at the link layer.
>>
>> 2) A new traffic control classifier (cls_cgroup) that can classify packets
>>   based on the tc_classid field in the socket to specific destination classes.
>>
>> An example of the use of this resource controller would be to limit the 
>> traffic from all tasks from a file_server cgroup to 100Mbps. We could 
>> achieve this by doing:
>>
>> # make a cgroup of file transfer processes and assign it a arbitrary 
>> unique # classid of 0x1234 - this will be used later to direct packets.
>> mkdir -p /dev/cgroup
>> mount -t cgroup tc -otc /dev/cgroup
>> mkdir /dev/cgroup/file_transfer
>> echo 0x1234 > /dev/cgroup/file_transfer/tc.classid
>> echo $PID_OF_FILE_XFER_PROCESS > /dev/cgroup/file_transfer/tasks
>>
>> # Now create a HTB class that rate limits traffic to 100mbits and 
>> attach # a filter to direct all traffic from cgroup file_transfer to this new class.
>> tc qdisc add dev eth0 root handle 1: htb tc class add dev eth0 parent 
>> 1: classid 1:10 htb rate 100mbit ceil 100mbit tc filter add dev eth0 
>> parent 1: handle 800 protocol ip prio 1 cgroup value 0x1234 classid 
>> 1:10
>>
>> Signed-off-by: Ranjit Manomohan <ranjitm <at> google.com>
>>
> 
> I installed your patch to kernel-2.6.27-rc7 with some hunkles but without failes.
> After compiling the kernel, I run the command which you wrote above. Most of all commands successfully are run except the last command " tc filter add dev eth0 parent 1: handle 800 protocol ip prio 1 cgroup value 0x1234 classid 1:10"
> 
> After that, I received this messages
> "Unknown filter "cgroup", hence option "value" is unparsable"
> 
> So I operated this command with "strace", then below messages returned.
> ...
> socket(PF_NETLINK, SOCK_RAW, 0)         = 3
> setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0 setsockopt(3, SOL_SOCKET, SO_RCVBUF, [32768], 4) = 0 bind(3, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0 getsockname(3, {sa_family=AF_NETLINK, pid=5452, groups=00000000}, [12]) = 0
> time(NULL)                              = 1222389948
> open("/usr/lib/tc/f_cgroup.so", O_RDONLY) = -1 ENOENT (No such file or directory) write(2, "Unknown filter \"cgroup\", hence o"..., 60Unknown filter "cgroup", hence option "value" is unparsable
I think there may be a file named f_cgroup.c in iproute-2.6.xxxx/tc/,
right? and it looks like tc_group should be supported by tc also.

Regards,
Zumeng
> ) = 60
> close(3)                                = 0
> exit_group(1)                           = ?
> 
> This messages told me tc couldn’t find "f_cgroup.so" library in my system.
> With this message, I thought that we need a modified "tc" command file to recognize the new filter, cgroup.
> 
> And I saw the line in your patch below
> ">Please consider for net-next-2.6."
> What's the meaning of the line?
> I wonder if I have to adopt another patch for net-netxt-2.6 before adopting this patch?
> 
> You didn't mentioned base kernel for this patch.
> I am willing to know the base kernel version and why you didn't mention.
> 
> I've worked couple of days for resolving this problem. But I couldn't find the proper answer yet.
> 
> I'd really thank you if you help me.
> 
> 
> To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo <at> vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> --
> 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/
> 

Re: [PATCH 0/2] Traffic control cgroups subsystem

[Chen Zumeng]

Hi Ranjit,

Acked the basic functional test of your patches QoS based
on controller group.

Regards,
Zumeng

Chen Zumeng wrote:
> 김재열 wrote:
>>> Incorporated fixes suggested by Li Zefan.
>>>
>>> Please consider for net-next-2.6.
>>>
>>> This patch provides a simple resource controller (cgroup_tc) based on 
>>> the cgroups infrastructure to manage network traffic. The cgroup_tc 
>>> resource controller can be used to schedule and shape traffic belonging 
>>> to the task(s) in a particular cgroup.
>>>
>>> The implementation consists of two parts:
>>>
>>> 1) A resource controller (cgroup_tc) that is used to associate packets from
>>>   a particular task belonging to a cgroup with a traffic control class id (
>>>   tc_classid). This tc_classid is propagated to all sockets created by tasks
>>>   in the cgroup and will be used for classifying packets at the link layer.
>>>
>>> 2) A new traffic control classifier (cls_cgroup) that can classify packets
>>>   based on the tc_classid field in the socket to specific destination classes.
>>>
>>> An example of the use of this resource controller would be to limit the 
>>> traffic from all tasks from a file_server cgroup to 100Mbps. We could 
>>> achieve this by doing:
>>>
>>> # make a cgroup of file transfer processes and assign it a arbitrary 
>>> unique # classid of 0x1234 - this will be used later to direct packets.
>>> mkdir -p /dev/cgroup
>>> mount -t cgroup tc -otc /dev/cgroup
>>> mkdir /dev/cgroup/file_transfer
>>> echo 0x1234 > /dev/cgroup/file_transfer/tc.classid
>>> echo $PID_OF_FILE_XFER_PROCESS > /dev/cgroup/file_transfer/tasks
>>>
>>> # Now create a HTB class that rate limits traffic to 100mbits and 
>>> attach # a filter to direct all traffic from cgroup file_transfer to this new class.
>>> tc qdisc add dev eth0 root handle 1: htb tc class add dev eth0 parent 
>>> 1: classid 1:10 htb rate 100mbit ceil 100mbit tc filter add dev eth0 
>>> parent 1: handle 800 protocol ip prio 1 cgroup value 0x1234 classid 
>>> 1:10
>>>
>>> Signed-off-by: Ranjit Manomohan <ranjitm <at> google.com>
>>>
>> I installed your patch to kernel-2.6.27-rc7 with some hunkles but without failes.
>> After compiling the kernel, I run the command which you wrote above. Most of all commands successfully are run except the last command " tc filter add dev eth0 parent 1: handle 800 protocol ip prio 1 cgroup value 0x1234 classid 1:10"
>>
>> After that, I received this messages
>> "Unknown filter "cgroup", hence option "value" is unparsable"
>>
>> So I operated this command with "strace", then below messages returned.
>> ...
>> socket(PF_NETLINK, SOCK_RAW, 0)         = 3
>> setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0 setsockopt(3, SOL_SOCKET, SO_RCVBUF, [32768], 4) = 0 bind(3, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0 getsockname(3, {sa_family=AF_NETLINK, pid=5452, groups=00000000}, [12]) = 0
>> time(NULL)                              = 1222389948
>> open("/usr/lib/tc/f_cgroup.so", O_RDONLY) = -1 ENOENT (No such file or directory) write(2, "Unknown filter \"cgroup\", hence o"..., 60Unknown filter "cgroup", hence option "value" is unparsable
> I think there may be a file named f_cgroup.c in iproute-2.6.xxxx/tc/,
> right? and it looks like tc_group should be supported by tc also.
> 
> Regards,
> Zumeng
>> ) = 60
>> close(3)                                = 0
>> exit_group(1)                           = ?
>>
>> This messages told me tc couldn’t find "f_cgroup.so" library in my system.
>> With this message, I thought that we need a modified "tc" command file to recognize the new filter, cgroup.
>>
>> And I saw the line in your patch below
>> ">Please consider for net-next-2.6."
>> What's the meaning of the line?
>> I wonder if I have to adopt another patch for net-netxt-2.6 before adopting this patch?
>>
>> You didn't mentioned base kernel for this patch.
>> I am willing to know the base kernel version and why you didn't mention.
>>
>> I've worked couple of days for resolving this problem. But I couldn't find the proper answer yet.
>>
>> I'd really thank you if you help me.
>>
>>
>> To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo <at> vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>> --
>> 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/
>>
> 
> 

Re: [PATCH 0/2] Traffic control cgroups subsystem

[김재열]

>Incorporated fixes suggested by Li Zefan.
>
>Please consider for net-next-2.6.
>
>This patch provides a simple resource controller (cgroup_tc) based on the
>cgroups infrastructure to manage network traffic. The cgroup_tc resource
>controller can be used to schedule and shape traffic belonging to the task(s)
>in a particular cgroup.
>
>The implementation consists of two parts:
>
>1) A resource controller (cgroup_tc) that is used to associate packets from
>   a particular task belonging to a cgroup with a traffic control class id (
>   tc_classid). This tc_classid is propagated to all sockets created by tasks
>   in the cgroup and will be used for classifying packets at the link layer.
>
>2) A new traffic control classifier (cls_cgroup) that can classify packets
>   based on the tc_classid field in the socket to specific destination classes.
>
>An example of the use of this resource controller would be to limit
>the traffic from all tasks from a file_server cgroup to 100Mbps. We could
>achieve this by doing:
>
># make a cgroup of file transfer processes and assign it a arbitrary unique
># classid of 0x1234 - this will be used later to direct packets.
>mkdir -p /dev/cgroup
>mount -t cgroup tc -otc /dev/cgroup
>mkdir /dev/cgroup/file_transfer
>echo 0x1234 > /dev/cgroup/file_transfer/tc.classid
>echo $PID_OF_FILE_XFER_PROCESS > /dev/cgroup/file_transfer/tasks
>
># Now create a HTB class that rate limits traffic to 100mbits and attach
># a filter to direct all traffic from cgroup file_transfer to this new class.
>tc qdisc add dev eth0 root handle 1: htb
>tc class add dev eth0 parent 1: classid 1:10 htb rate 100mbit ceil 100mbit
>tc filter add dev eth0 parent 1: handle 800 protocol ip prio 1 cgroup value 0x1234 classid 1:10
>
>Signed-off-by: Ranjit Manomohan <ranjitm <at> google.com>
>

I installed your patch to kernel-2.6.27-rc7 with some hunkles but without failes.
After compiling the kernel, I run the command which you wrote above. Most of all commands successfully are run except the last command " tc filter add dev eth0 parent 1: handle 800 protocol ip prio 1 cgroup value 0x1234 classid 1:10"

After that, I received this messages
"Unknown filter "cgroup", hence option "value" is unparsable"

So I operated this command with "strace", then below messages returned.
...
socket(PF_NETLINK, SOCK_RAW, 0)         = 3
setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0
setsockopt(3, SOL_SOCKET, SO_RCVBUF, [32768], 4) = 0
bind(3, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0
getsockname(3, {sa_family=AF_NETLINK, pid=5452, groups=00000000}, [12]) = 0
time(NULL)                              = 1222389948
open("/usr/lib/tc/f_cgroup.so", O_RDONLY) = -1 ENOENT (No such file or directory)
write(2, "Unknown filter \"cgroup\", hence o"..., 60Unknown filter "cgroup", hence option "value" is unparsable
) = 60
close(3)                                = 0
exit_group(1)                           = ?

This messages told me tc couldn’t find "f_cgroup.so" library in my system.
With this message, I thought that we need a modified "tc" command file to recognize the new filter, cgroup.

And I saw the line in your patch below
">Please consider for net-next-2.6."
What's the meaning of the line?
I wonder if I have to adopt another patch for net-netxt-2.6 before adopting this patch?

You didn't mentioned base kernel for this patch.
I am willing to know the base kernel version and why you didn't mention.

I've worked couple of days for resolving this problem. But I couldn't find the proper answer yet.

I'd really thank you if you help me.


To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] Traffic control cgroups subsystem

[Ranjit Manomohan]

Incorporated fixes suggested by Li Zefan.

Please consider for net-next-2.6.

This patch provides a simple resource controller (cgroup_tc) based on the
cgroups infrastructure to manage network traffic. The cgroup_tc resource
controller can be used to schedule and shape traffic belonging to the task(s)
in a particular cgroup.

The implementation consists of two parts:

1) A resource controller (cgroup_tc) that is used to associate packets from
   a particular task belonging to a cgroup with a traffic control class id (
   tc_classid). This tc_classid is propagated to all sockets created by tasks
   in the cgroup and will be used for classifying packets at the link layer.

2) A new traffic control classifier (cls_cgroup) that can classify packets
   based on the tc_classid field in the socket to specific destination classes.

An example of the use of this resource controller would be to limit
the traffic from all tasks from a file_server cgroup to 100Mbps. We could
achieve this by doing:

# make a cgroup of file transfer processes and assign it a arbitrary unique
# classid of 0x1234 - this will be used later to direct packets.
mkdir -p /dev/cgroup
mount -t cgroup tc -otc /dev/cgroup
mkdir /dev/cgroup/file_transfer
echo 0x1234 > /dev/cgroup/file_transfer/tc.classid
echo $PID_OF_FILE_XFER_PROCESS > /dev/cgroup/file_transfer/tasks

# Now create a HTB class that rate limits traffic to 100mbits and attach
# a filter to direct all traffic from cgroup file_transfer to this new class.
tc qdisc add dev eth0 root handle 1: htb
tc class add dev eth0 parent 1: classid 1:10 htb rate 100mbit ceil 100mbit
tc filter add dev eth0 parent 1: handle 800 protocol ip prio 1 cgroup value 0x1234 classid 1:10

Signed-off-by: Ranjit Manomohan <ranjitm@google.com>

---

Re: [PATCH 0/2] Traffic control cgroups subsystem

[David Miller]

I definitely prefer Thomas Graf's work, this stuff is very ugly
and way overengineered.

So no, I won't consider for net-next-2.6, sorry.

Re: [PATCH 0/2] Traffic control cgroups subsystem

[Ranjit Manomohan]

On Wed, Sep 10, 2008 at 1:22 PM, David Miller <davem@davemloft.net> 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.

I'd be ok if you accepted either change since  we just want a standard
kernel mechanism to do this.

-Thanks,
Ranjit

> So no, I won't consider for net-next-2.6, sorry.
>
>

Re: [PATCH 0/2] Traffic control cgroups subsystem

[Thomas Graf]

* Ranjit Manomohan <ranjitm@google.com> 2008-09-10 13:44
> On Wed, Sep 10, 2008 at 1:22 PM, David Miller <davem@davemloft.net> 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.

> 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.

Re: [PATCH 0/2] Traffic control cgroups subsystem

[Ranjit Manomohan]

On Wed, Sep 10, 2008 at 3:12 PM, Thomas Graf <tgraf@suug.ch> wrote:
> * Ranjit Manomohan <ranjitm@google.com> 2008-09-10 13:44
>> On Wed, Sep 10, 2008 at 1:22 PM, David Miller <davem@davemloft.net> 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.
>

Re: [PATCH 0/2] Traffic control cgroups subsystem

[Thomas Graf]

* Ranjit Manomohan <ranjitm@google.com> 2008-09-10 16:37
> 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.

It works fairly well for a small number of bulk streams when no packets
need to be dropped. The results get very inaccurate for higher number
of smaller streams when packets start getting dropped. The problem is
simply that currently none of the congestion notification mechanism
work in (internet) practice.

Therefore I think that it is not worth the effort. If you think
diffrently, I will be more than glad to review code. So far I haven't
seen anything that would work on ingress.

[PATCH 0/2] Traffic control cgroups subsystem

[Ranjit Manomohan]

[Resend based of net-next-2.6, for 2.6.28]

This patch provides a simple resource controller (cgroup_tc) based on the
cgroups infrastructure to manage network traffic. The cgroup_tc resource
controller can be used to schedule and shape traffic belonging to the task(s)
in a particular cgroup.

The implementation consists of two parts:

1) A resource controller (cgroup_tc) that is used to associate packets from
   a particular task belonging to a cgroup with a traffic control class id (
   tc_classid). This tc_classid is propagated to all sockets created by tasks
   in the cgroup and will be used for classifying packets at the link layer.

2) A new traffic control classifier (cls_cgroup) that can classify packets
   based on the tc_classid field in the socket to specific destination classes.

An example of the use of this resource controller would be to limit
the traffic from all tasks from a file_server cgroup to 100Mbps. We could
achieve this by doing:

# make a cgroup of file transfer processes and assign it a arbitrary unique
# classid of 0x1234 - this will be used later to direct packets.
mkdir -p /dev/cgroup
mount -t cgroup tc -otc /dev/cgroup
mkdir /dev/cgroup/file_transfer
echo 0x1234 > /dev/cgroup/file_transfer/tc.classid
echo $PID_OF_FILE_XFER_PROCESS > /dev/cgroup/file_transfer/tasks

# Now create a HTB class that rate limits traffic to 100mbits and attach
# a filter to direct all traffic from cgroup file_transfer to this new class.
tc qdisc add dev eth0 root handle 1: htb
tc class add dev eth0 parent 1: classid 1:10 htb rate 100mbit ceil 100mbit
tc filter add dev eth0 parent 1: handle 800 protocol ip prio 1 cgroup value 0x1234 classid 1:10

Signed-off-by: Ranjit Manomohan <ranjitm@google.com>

---

[PATCH 0/2] Traffic control cgroups subsystem

[Ranjit Manomohan]

This set of patches provides a simple resource controller (cgroup_tc) based
on the cgroups infrastructure to manage network traffic. The cgroup_tc resource
controller can be used to schedule and shape traffic belonging to the task(s)
in a particular cgroup.

The implementation consists of two parts:

1) A resource controller (cgroup_tc) that is used to associate packets from
    a particular task belonging to a cgroup with a traffic control class id (
    tc_classid). This tc_classid is propagated to all sockets created by tasks
    in the cgroup and from there to all packets associated with those sockets.

2) A new traffic control classifier (cls_cgroup) that can classify packets
    based on the tc_classid field in the packet to specific destination classes.

A simple example of the use of this resource controller would be to limit
the traffic from all tasks from a file_server cgroup to 100Mbps. We could
achieve this by doing:

# make a cgroup of file transfer processes and assign it a uniqe classid
# of 0x1234
mkdir -p /dev/cgroup
mount -t cgroup tc -otc /dev/cgroup
mkdir /dev/cgroup/file_transfer
echo 0x1234 > /dev/cgroup/file_transfer/tc.classid
echo $PID_OF_FILE_XFER_PROCESS > /dev/cgroup/file_transfer/tasks

# Now create a HTB class that rate limits traffic to 100mbits and attach
# a filter to direct all traffic from cgroup file_transfer to this new class.
tc qdisc add dev eth0 root handle 1: htb
tc class add dev eth0 parent 1: classid 1:2 htb rate 100mbit ceil 100mbit
tc filter add dev eth0 parent 1: protocol ip prio 1 handle 800 cgroup value 0x1234 classid 1:2

Signed-off-by: Ranjit Manomohan <ranjitm@google.com>

---