* [RFC PATCH net-next 0/4] net_cls for sys container
@ 2014-01-03 3:11 Libo Chen
2014-01-03 5:20 ` Cong Wang
0 siblings, 1 reply; 6+ messages in thread
From: Libo Chen @ 2014-01-03 3:11 UTC (permalink / raw)
To: David Miller, jhs, Li Zefan
Cc: edumazet, pshelar, jasowang, horms, Serge Hallyn, netdev,
cgroups, containers, kaber, xemul, LKML
Hi guys,
Now, lxc created with veth can not be under control by
cls_cgroup.
the former discussion:
http://lkml.indiana.edu/hypermail/linux/kernel/1312.1/00214.html
In short, because cls_cgroup relys classid attached to sock
filter skb, but sock will be cleared inside dev_forward_skb()
in veth_xmit().
so I add backup_classid in struct sk_buffer to save classid
before dev_forward_skb(). In cls_cgroup_classify(), if skb->sk
is NULL, we can try to restore classid form skb->bk_classid.
Libo Chen (4):
net: introduce bk_classid to struct sk_buff
cls_cgroup: introduce a helper: bk_cls_classid()
veth: backup classid befor switch net_ns
cls_cgroup: restore classid from skb->sk_classid
drivers/net/veth.c | 5 +++++
include/linux/skbuff.h | 3 +++
include/net/cls_cgroup.h | 11 +++++++++++
net/sched/cls_cgroup.c | 8 ++++----
4 files changed, 23 insertions(+), 4 deletions(-)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC PATCH net-next 0/4] net_cls for sys container
2014-01-03 3:11 [RFC PATCH net-next 0/4] net_cls for sys container Libo Chen
@ 2014-01-03 5:20 ` Cong Wang
2014-01-06 7:54 ` Libo Chen
0 siblings, 1 reply; 6+ messages in thread
From: Cong Wang @ 2014-01-03 5:20 UTC (permalink / raw)
To: Libo Chen
Cc: David Miller, Jamal Hadi Salim, Li Zefan, Eric Dumazet, pshelar,
jasowang, Simon Horman, Serge Hallyn,
Linux Kernel Network Developers, cgroups, containers,
Patrick McHardy, xemul, LKML
On Thu, Jan 2, 2014 at 7:11 PM, Libo Chen <clbchenlibo.chen@huawei.com> wrote:
> Hi guys,
>
> Now, lxc created with veth can not be under control by
> cls_cgroup.
>
> the former discussion:
> http://lkml.indiana.edu/hypermail/linux/kernel/1312.1/00214.html
>
> In short, because cls_cgroup relys classid attached to sock
> filter skb, but sock will be cleared inside dev_forward_skb()
> in veth_xmit().
So what are you trying to achieve here?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC PATCH net-next 0/4] net_cls for sys container
2014-01-03 5:20 ` Cong Wang
@ 2014-01-06 7:54 ` Libo Chen
2014-01-06 8:42 ` Gao feng
0 siblings, 1 reply; 6+ messages in thread
From: Libo Chen @ 2014-01-06 7:54 UTC (permalink / raw)
To: Cong Wang
Cc: David Miller, Jamal Hadi Salim, Li Zefan, Eric Dumazet, pshelar,
jasowang, Simon Horman, Serge Hallyn,
Linux Kernel Network Developers, cgroups, containers,
Patrick McHardy, xemul, LKML
On 2014/1/3 13:20, Cong Wang wrote:
> On Thu, Jan 2, 2014 at 7:11 PM, Libo Chen <clbchenlibo.chen@huawei.com> wrote:
>> Hi guys,
>>
>> Now, lxc created with veth can not be under control by
>> cls_cgroup.
>>
>> the former discussion:
>> http://lkml.indiana.edu/hypermail/linux/kernel/1312.1/00214.html
>>
>> In short, because cls_cgroup relys classid attached to sock
>> filter skb, but sock will be cleared inside dev_forward_skb()
>> in veth_xmit().
>
>
> So what are you trying to achieve here?
sys container using veth can be controlled by cls_cgroup basing on physic network interface
thanks,
Libo
>
> .
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC PATCH net-next 0/4] net_cls for sys container
2014-01-06 7:54 ` Libo Chen
@ 2014-01-06 8:42 ` Gao feng
2014-01-06 10:06 ` Libo Chen
0 siblings, 1 reply; 6+ messages in thread
From: Gao feng @ 2014-01-06 8:42 UTC (permalink / raw)
To: Libo Chen, Cong Wang
Cc: David Miller, Jamal Hadi Salim, Li Zefan, Eric Dumazet, pshelar,
jasowang, Simon Horman, Serge Hallyn,
Linux Kernel Network Developers, cgroups, containers,
Patrick McHardy, xemul, LKML
On 01/06/2014 03:54 PM, Libo Chen wrote:
> On 2014/1/3 13:20, Cong Wang wrote:
>> On Thu, Jan 2, 2014 at 7:11 PM, Libo Chen <clbchenlibo.chen@huawei.com> wrote:
>>> Hi guys,
>>>
>>> Now, lxc created with veth can not be under control by
>>> cls_cgroup.
>>>
>>> the former discussion:
>>> http://lkml.indiana.edu/hypermail/linux/kernel/1312.1/00214.html
>>>
>>> In short, because cls_cgroup relys classid attached to sock
>>> filter skb, but sock will be cleared inside dev_forward_skb()
>>> in veth_xmit().
>>
>>
>> So what are you trying to achieve here?
>
> sys container using veth can be controlled by cls_cgroup basing on physic network interface
>
It's a problem about virtual nic, not container/net namespace.
If veth device is running in host. the skb is transmitted firstly by veth device and then delivered
by physical device. if you set both qdisc rule on veth and physical device. which qdisc rule will take
effect?
In your patch, both qdisc rule are effective. it looks strange.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC PATCH net-next 0/4] net_cls for sys container
2014-01-06 8:42 ` Gao feng
@ 2014-01-06 10:06 ` Libo Chen
2014-01-15 0:50 ` Eric W. Biederman
0 siblings, 1 reply; 6+ messages in thread
From: Libo Chen @ 2014-01-06 10:06 UTC (permalink / raw)
To: Gao feng, Cong Wang
Cc: David Miller, Jamal Hadi Salim, Li Zefan, Eric Dumazet, pshelar,
jasowang, Simon Horman, Serge Hallyn,
Linux Kernel Network Developers, cgroups, containers,
Patrick McHardy, xemul, LKML
yes
On 2014/1/6 16:42, Gao feng wrote:
> On 01/06/2014 03:54 PM, Libo Chen wrote:
>> On 2014/1/3 13:20, Cong Wang wrote:
>>> On Thu, Jan 2, 2014 at 7:11 PM, Libo Chen <clbchenlibo.chen@huawei.com> wrote:
>>>> Hi guys,
>>>>
>>>> Now, lxc created with veth can not be under control by
>>>> cls_cgroup.
>>>>
>>>> the former discussion:
>>>> http://lkml.indiana.edu/hypermail/linux/kernel/1312.1/00214.html
>>>>
>>>> In short, because cls_cgroup relys classid attached to sock
>>>> filter skb, but sock will be cleared inside dev_forward_skb()
>>>> in veth_xmit().
>>>
>>>
>>> So what are you trying to achieve here?
>>
>> sys container using veth can be controlled by cls_cgroup basing on physic network interface
>>
>
> It's a problem about virtual nic, not container/net namespace.
yes
>
> If veth device is running in host. the skb is transmitted firstly by veth device and then delivered
> by physical device. if you set both qdisc rule on veth and physical device. which qdisc rule will take
> effect?
both, the end result depends on a smaller.
>
> In your patch, both qdisc rule are effective. it looks strange.
>
qdisc is based nic, does not distinguish virtual or physics. if you are all set,
it means that what you want. so the logic is not the problemI and this appears to be normal.
thanks,
Libo
> .
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC PATCH net-next 0/4] net_cls for sys container
2014-01-06 10:06 ` Libo Chen
@ 2014-01-15 0:50 ` Eric W. Biederman
0 siblings, 0 replies; 6+ messages in thread
From: Eric W. Biederman @ 2014-01-15 0:50 UTC (permalink / raw)
To: Libo Chen
Cc: Gao feng, Cong Wang, Simon Horman, Patrick McHardy,
Linux Kernel Network Developers, jasowang, Serge Hallyn, pshelar,
Eric Dumazet, cgroups, containers, David Miller, LKML, xemul
Libo Chen <clbchenlibo.chen@huawei.com> writes:
> yes
> On 2014/1/6 16:42, Gao feng wrote:
>> On 01/06/2014 03:54 PM, Libo Chen wrote:
>>> On 2014/1/3 13:20, Cong Wang wrote:
>>>> On Thu, Jan 2, 2014 at 7:11 PM, Libo Chen <clbchenlibo.chen@huawei.com> wrote:
>>>>> Hi guys,
>>>>>
>>>>> Now, lxc created with veth can not be under control by
>>>>> cls_cgroup.
>>>>>
>>>>> the former discussion:
>>>>> http://lkml.indiana.edu/hypermail/linux/kernel/1312.1/00214.html
>>>>>
>>>>> In short, because cls_cgroup relys classid attached to sock
>>>>> filter skb, but sock will be cleared inside dev_forward_skb()
>>>>> in veth_xmit().
>>>>
>>>>
>>>> So what are you trying to achieve here?
>>>
>>> sys container using veth can be controlled by cls_cgroup basing on physic network interface
>>>
>>
>> It's a problem about virtual nic, not container/net namespace.
>
> yes
>
>>
>> If veth device is running in host. the skb is transmitted firstly by veth device and then delivered
>> by physical device. if you set both qdisc rule on veth and physical device. which qdisc rule will take
>> effect?
>
> both, the end result depends on a smaller.
>
>>
>> In your patch, both qdisc rule are effective. it looks strange.
>>
>
> qdisc is based nic, does not distinguish virtual or physics. if you are all set,
> it means that what you want. so the logic is not the problemI and this appears to be normal.
My personal opinion on the matter is that the network class cgroup is
brain dead and should not be used. It is impossible to use for
incomming packets, and it is part of the the problem plagued cgroup
subsystem.
You have real network interfaces to do your classification with you
don't need to enhance the network class cgroup.
The more this is asked about the more I think the network class cgroup
should be be taken out into the woods some dark night and left in a
shallow grave, never to bother us again.
Eric
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-01-15 0:50 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-01-03 3:11 [RFC PATCH net-next 0/4] net_cls for sys container Libo Chen
2014-01-03 5:20 ` Cong Wang
2014-01-06 7:54 ` Libo Chen
2014-01-06 8:42 ` Gao feng
2014-01-06 10:06 ` Libo Chen
2014-01-15 0:50 ` Eric W. Biederman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).