Re: [patch net-next v8 08/14] net: sched: add rt netlink message type for block get

[David Ahern <dsahern@gmail.com>]

On 1/15/18 10:27 AM, Jiri Pirko wrote:
> Mon, Jan 15, 2018 at 06:21:44PM CET, dsahern@gmail.com wrote:
>> On 1/15/18 10:08 AM, David Ahern wrote:
>>> On 1/15/18 10:03 AM, Jiri Pirko wrote:
>>>> Mon, Jan 15, 2018 at 05:56:31PM CET, dsahern@gmail.com wrote:
>>>>> On 1/12/18 8:46 AM, Jiri Pirko wrote:
>>>>>> From: Jiri Pirko <jiri@mellanox.com>
>>>>>
>>>>> Why can't this be done with RTM_GETQDISC?
>>>>
>>>> I don't follow. Could you please describe a bit more what do you think?
>>>
>>> Why are you adding RTM_{NEW,GET,DEL}BLOCK? Can't you get the same
>>> information using RTM_GETQDISC and updating it to check for the
>>> 'tcm_ifindex == TCM_IFINDEX_MAGIC_BLOCK' path
> 
> I might, but it bould be an ugly hack. I would use cmd that is used to
> manipulate qdisc to some entirely different purpose. That does not make
> any sense to me :(
> 
> 
> 
>>>
>>
>> The above question is because a user specifies a shared block in a
>> 'qdisc add'.
> 
> Qdisc and block is a different entity
> 
> 
>>
>> Alternatively, what about RTM_GETTFILTER? You already update
>> tc_ctl_tfilter to check for TCM_IFINDEX_MAGIC_BLOCK
> 
> The object is still filter! Only the handle is different. You cannot
> compare that, sorry.
> 
> 
>>
>> My main question is why can't existing RTM_ commands be used?

What I am struggling with is the idea that you need a new set of RTM_
commands to see if a block exists or to get notifications of a change to
a block, but you don't need that API to create or modify the blocks.