On 1/15/18 10:27 AM, Jiri Pirko wrote:
> Mon, Jan 15, 2018 at 06:21:44PM CET, dsah...@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, dsah...@gmail.com wrote:
>>>>> On 1/12/18 8:46 AM, Jiri Pirko wrote:
>>>>>> From: Jiri Pirko <j...@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.
