Fri, Apr 28, 2017 at 07:40:24PM CEST, xiyou.wangc...@gmail.com wrote:
>On Thu, Apr 27, 2017 at 11:53 PM, Jiri Pirko <j...@resnulli.us> wrote:
>> Thu, Apr 27, 2017 at 07:46:03PM CEST, xiyou.wangc...@gmail.com wrote:
>>>On Thu, Apr 27, 2017 at 4:12 AM, Jiri Pirko <j...@resnulli.us> wrote:
>>>> Simple example:
>>>> $ tc qdisc add dev eth0 ingress
>>>> $ tc filter add dev eth0 parent ffff: protocol ip pref 33 flower dst_mac
>>>> 52:54:00:3d:c7:6d action goto chain 11
>>>> $ tc filter add dev eth0 parent ffff: protocol ip pref 22 chain 11 flower
>>>> dst_ip 192.168.40.1 action drop
>>>> $ tc filter show dev eth0 root
>>>
>>>Interesting.
>>>
>>>I don't look into the code yet. If I understand the concepts correctly,
>>>so with your patchset we can mark either filter with a chain No. to
>>>choose which chain it belongs to _logically_ even though
>>>_physically_ it is still in the old-fashion chain (prio, proto)?
>>
>> You have to see the code :)
>
>I don't understand why I have to, these are high-level concepts
>and should be put in your cover letter (aka. design doc). You miss
>a lot of information about the ordering here.
Well, the description is one thing, but seeing the actual code should
put the whole view. But if you are missing something, I can add it. What
do you mean by "information about the ordering"?
>
>Also the terms you use are confusing too, without your patchset
>we have chains too, struct tcf_proto is a chain, each kind of filter
>defines their own way to store their filters into this chain (tp->root),
Those are internal structures specific to each filter. Not "chains" per
say.
>and of course tp is chained in a singly-linked list too which turns
>into multiple-chains.
