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

On 1/15/18 10:27 AM, Jiri Pirko wrote:

Mon, Jan 15, 2018 at 06:21:44PM CET, dsahern@gmail.com wrote:

quoted

On 1/15/18 10:08 AM, David Ahern wrote:

quoted

On 1/15/18 10:03 AM, Jiri Pirko wrote:

quoted

Mon, Jan 15, 2018 at 05:56:31PM CET, dsahern@gmail.com wrote:

quoted

On 1/12/18 8:46 AM, Jiri Pirko wrote:

quoted

From: Jiri Pirko <redacted>

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 :(

quoted

quoted

The above question is because a user specifies a shared block in a
'qdisc add'.

Qdisc and block is a different entity

quoted

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.

quoted

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.