[Devel] Re: [PATCH 1/1] cls_cgroup: unify classid syntax to tc

Minoru Usui usui at mxm.nes.nec.co.jp
Wed Jun 17 23:15:16 PDT 2009


On Thu, 18 Jun 2009 10:01:27 +0800
Li Zefan <lizf at cn.fujitsu.com> wrote:

> Minoru Usui wrote:
> > On Mon, 15 Jun 2009 06:19:19 -0400
> > Thomas Graf <tgraf at infradead.org> wrote:
> > 
> >> On Mon, Jun 15, 2009 at 12:00:35PM +0900, Minoru Usui wrote:
> >>> Actually, In tc <-> kernel I/F (which uses netlink), tc sets classid to hexadecimal style not X:Y style.
> >>> X:Y style is result of translating by tc command.
> >>>
> >>> I thought this patch was very useful at first, but it's not necessary to implementing to the kernel.
> >>> This function can be implemented on user space if we need.
> >>> And we can also keep compatibility of net_cls.classid I/F. :-)
> >>>
> >>> I drop this patch. I'm sorry for confusing a lot of people.
> >> I found this patch to be extremely useful if it wasn't to break
> >> compatibility but that issue can be resolved by accepting both
> >> formats easly.
> > 
> > Thank you for agreeing my patch.
> > 
> > I think you said write format only. Am I right?
> > What do you think about read format?
> > Do you think you should keep read format as current implementation?
> > 
> > I think we should need to unify read/write format, if we make cls_cgroup is more userfriendly. 
> > Because some of people are confused about having to read their write value as different format.
> > (Unfortunately, current implementation is so...)
> > 
> > But this approach breaks compatibility, so I drop this patch.
> 
> How about adding a new control file net_cls.tc_classid?
> 

net_cls.classid's core purpose is to read/write classid. 
If we add net_cls.tc_classid, its core purpose is same.
Their difference is only read/write value of expression.

Is this approach ok?

-- 
Minoru Usui <usui at mxm.nes.nec.co.jp>
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers




More information about the Devel mailing list