Re: [patch net-next v4 00/10] net: sched: allow qdiscs to share filter block instances

[Jiri Pirko <jiri@resnulli.us>]

Sun, Dec 24, 2017 at 02:54:47AM CET, dsahern@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.