From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Ahern Subject: Re: [patch net-next v8 08/14] net: sched: add rt netlink message type for block get Date: Mon, 15 Jan 2018 10:44:41 -0700 Message-ID: References: <20180112154704.1694-1-jiri@resnulli.us> <20180112154704.1694-9-jiri@resnulli.us> <5ac63554-fdcc-b392-aa80-4889756b233f@gmail.com> <20180115170354.GD2103@nanopsycho> <630fad8f-f72b-d857-bd09-fa9e361659f3@gmail.com> <20180115172702.GE2103@nanopsycho> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, davem@davemloft.net, jhs@mojatatu.com, xiyou.wangcong@gmail.com, mlxsw@mellanox.com, andrew@lunn.ch, vivien.didelot@savoirfairelinux.com, f.fainelli@gmail.com, michael.chan@broadcom.com, ganeshgr@chelsio.com, saeedm@mellanox.com, matanb@mellanox.com, leonro@mellanox.com, idosch@mellanox.com, jakub.kicinski@netronome.com, simon.horman@netronome.com, pieter.jansenvanvuuren@netronome.com, john.hurley@netronome.com, alexander.h.duyck@intel.com, ogerlitz@mellanox.com, john.fastabend@gmail.com, daniel@iogearbox.net To: Jiri Pirko Return-path: Received: from mail-pl0-f66.google.com ([209.85.160.66]:39689 "EHLO mail-pl0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933786AbeAORoo (ORCPT ); Mon, 15 Jan 2018 12:44:44 -0500 Received: by mail-pl0-f66.google.com with SMTP id bi12so4199658plb.6 for ; Mon, 15 Jan 2018 09:44:44 -0800 (PST) In-Reply-To: <20180115172702.GE2103@nanopsycho> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: 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 >>>>> >>>>> 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.