Re: [RFC PATCH net-next 0/4] net_cls for sys container
Libo Chen 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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [RFC PATCH net-next 0/4] net_cls for sys container
Libo Chen clbchenlibo.c...@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.c...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: [RFC PATCH net-next 0/4] net_cls for sys container
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 >>> 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 > . > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [RFC PATCH net-next 0/4] net_cls for sys container
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 >> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [RFC PATCH net-next 0/4] net_cls for sys container
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.c...@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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: [RFC PATCH net-next 0/4] net_cls for sys container
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.c...@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 . -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: [RFC PATCH net-next 0/4] net_cls for sys container
On 2014/1/3 13:20, Cong Wang wrote: > On Thu, Jan 2, 2014 at 7:11 PM, Libo Chen 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 > > . > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [RFC PATCH net-next 0/4] net_cls for sys container
On 2014/1/3 13:20, Cong Wang wrote: On Thu, Jan 2, 2014 at 7:11 PM, Libo Chen clbchenlibo.c...@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 . -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: [RFC PATCH net-next 0/4] net_cls for sys container
On Thu, Jan 2, 2014 at 7:11 PM, Libo Chen 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? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH net-next 0/4] 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(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH net-next 0/4] 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(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: [RFC PATCH net-next 0/4] net_cls for sys container
On Thu, Jan 2, 2014 at 7:11 PM, Libo Chen clbchenlibo.c...@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? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
