Sun, Dec 24, 2017 at 02:54:47AM CET, dsah...@gmail.com wrote: >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?
Again, no resistance, I said many times it would be done as a follow-up. But as an api already exists, it has to continue to work. Or do you suggest it should stop working? That, I don't agree with.
