Skip to contentSkip to conversation

net_cls for sys container

RFC PATCH In review Libo Chen 7 participants 10 messages Jan 3, 2014 – Jan 15, 2014 4 messages not in the archive

Subsystems (3)
Networking Network drivers cgroup
lore
Share & tools
lore

Libo Chen

author
#0 lore raw

cover net_cls for sys container

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(-)
#1 lore raw
Quoted 11 lines · Libo Chen

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?

author
#2 lore raw
Quoted 9 lines · Cong Wang
Quoted 8 lines · Libo Chen

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

Quoted 6 lines
Quoted 3 lines

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

Quoted 3 lines

.

#3 lore raw
Quoted 10 lines · Libo Chen
Quoted 9 lines · Cong Wang
Quoted 8 lines · Libo Chen

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

Quoted 9 lines
Quoted 6 lines
Quoted 3 lines

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.

author
#4 lore raw

yes

Quoted 16 lines · Gao feng
Quoted 15 lines · Libo Chen
Quoted 14 lines · Cong Wang
Quoted 11 lines · Libo Chen

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

Quoted 6 lines
Quoted 4 lines
Quoted 1 line

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

Quoted 4 lines

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.

Quoted 3 lines

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

Quoted 2 lines

.

#5 lore raw
Quoted 32 lines · Libo Chen

yes

Quoted 16 lines · Gao feng
Quoted 15 lines · Libo Chen
Quoted 14 lines · Cong Wang
Quoted 11 lines · Libo Chen

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

Quoted 6 lines
Quoted 4 lines
Quoted 1 line

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

Quoted 4 lines

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?

Quoted 8 lines

both, the end result depends on a smaller.

Quoted 3 lines

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

#7 lore raw
Quoted 32 lines · Libo Chen

yes

Quoted 16 lines · Gao feng
Quoted 15 lines · Libo Chen
Quoted 14 lines · Cong Wang
Quoted 11 lines · Libo Chen

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

Quoted 6 lines
Quoted 4 lines
Quoted 1 line

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

Quoted 4 lines

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?

Quoted 8 lines

both, the end result depends on a smaller.

Quoted 3 lines

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

#9 lore raw

yes

Quoted 16 lines · Gao feng
Quoted 15 lines · Libo Chen
Quoted 14 lines · Cong Wang
Quoted 11 lines · Libo Chen

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

Quoted 6 lines
Quoted 4 lines
Quoted 1 line

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

Quoted 4 lines

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.

Quoted 3 lines

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

Quoted 2 lines

.

A message that is not in the archive (sent off-list or not yet received): CAM_iQpW0+Ftvk=QBE+0yMNW00VkBee1+yAEmbPkT+zjij9RX-Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org

#11 lore raw
Quoted 9 lines · Cong Wang
Quoted 8 lines · Libo Chen

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

Quoted 6 lines
Quoted 3 lines

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

Quoted 3 lines

.

A message that is not in the archive (sent off-list or not yet received): [email protected]