On 12/23/17 9:54 AM, Jiri Pirko wrote: > So back to the example. First, we create 2 qdiscs. Both will share > block number 22. "22" is just an identification. If we don't pass any > block number, a new one will be generated by kernel: > > $ tc qdisc add dev ens7 ingress block 22 > ^^^^^^^^ > $ tc qdisc add dev ens8 ingress block 22 > ^^^^^^^^ > > Now if we list the qdiscs, we will see the block index in the output: > > $ tc qdisc > qdisc ingress ffff: dev ens7 parent ffff:fff1 block 22 > qdisc ingress ffff: dev ens8 parent ffff:fff1 block 22 > > To make is more visual, the situation looks like this: > > ens7 ingress qdisc ens7 ingress qdisc > | | > | | > +----------> block 22 <----------+ > > Unlimited number of qdiscs may share the same block. > > Now we can add filter to any of qdiscs sharing the same block: > > $ tc filter add dev ens7 ingress protocol ip pref 25 flower dst_ip > 192.168.0.0/16 action drop
Allowing config of a shared block through any qdisc that references it is akin to me allowing nexthop objects to be manipulated by any route that references it -- sure, it could be done but causes a lot surprises to the user. You are adding a new tc object -- a shared block. Why the resistance to creating a proper API for managing it?
