Libo Chen [off-list ref] writes:

yes
On 2014/1/6 16:42, Gao feng wrote:

quoted

On 01/06/2014 03:54 PM, Libo Chen wrote:

quoted

On 2014/1/3 13:20, Cong Wang wrote:

quoted

On Thu, Jan 2, 2014 at 7:11 PM, Libo Chen [off-list ref] wrote:

quoted

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

quoted

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

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