Wed, Jun 27, 2018 at 08:34:46AM CEST, sridhar.samudr...@intel.com wrote: > >On 6/26/2018 11:05 PM, Jiri Pirko wrote: >> Wed, Jun 27, 2018 at 02:04:31AM CEST, xiyou.wangc...@gmail.com wrote: >> > On Tue, Jun 26, 2018 at 1:01 AM Jiri Pirko <j...@resnulli.us> wrote: >> > > Create dummy device with clsact first: >> > > # ip link add type dummy >> > > # tc qdisc add dev dummy0 clsact >> > > >> > > There is no template assigned by default: >> > > # tc filter template show dev dummy0 ingress >> > > >> > > Add a template of type flower allowing to insert rules matching on last >> > > 2 bytes of destination mac address: >> > > # tc filter template add dev dummy0 ingress proto ip flower dst_mac >> > > 00:00:00:00:00:00/00:00:00:00:FF:FF >> > Now you are extending 'tc filter' command with a new >> > subcommand 'template', which looks weird. >> > >> > Why not make it a new property of filter like you did for chain? >> > Like: >> > >> > tc filter add dev dummy0 ingress proto ip template flower >> But unlike chain, this is not a filter property. For chain, when you add >> filter, you add it to a specific chain. That makes sense. >> But for template, you need to add the template first. Then, later on, >> you add filters which either match or does not match the template. > >So can we say that template defines the types of rules(match fields/masks) that >can be added to a specific chain and there is 1-1 relationship between a >template >and a chain?
yes > >Without attaching a template to a chain, i guess it is possible to add >different >types of rules to a chain? yes > > >> Does not make sense to have "template" the filter property as you >> suggest. > >template seems to a chain property. yes > >> > which is much better IMHO. >
