From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jiri Pirko Subject: Re: [patch net-next v8 08/14] net: sched: add rt netlink message type for block get Date: Mon, 15 Jan 2018 18:27:02 +0100 Message-ID: <20180115172702.GE2103@nanopsycho> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: David Ahern Return-path: Received: from mail-wr0-f196.google.com ([209.85.128.196]:45348 "EHLO mail-wr0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965533AbeAOR1E (ORCPT ); Mon, 15 Jan 2018 12:27:04 -0500 Received: by mail-wr0-f196.google.com with SMTP id 16so12498569wry.12 for ; Mon, 15 Jan 2018 09:27:04 -0800 (PST) Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: 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 >>>>> >>>>> Add simple block get operation which primary purpose is to check the >>>>> block existence by block index. >>>>> >>>>> Signed-off-by: Jiri Pirko >>>>> --- >>>>> v6->v7: >>>>> - new patch >>>>> --- >>>>> include/uapi/linux/rtnetlink.h | 6 ++++ >>>>> net/sched/cls_api.c | 64 ++++++++++++++++++++++++++++++++++++++++++ >>>>> security/selinux/nlmsgtab.c | 5 +++- >>>>> 3 files changed, 74 insertions(+), 1 deletion(-) >>>>> >>>>> diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h >>>>> index da878f2..4b1f626 100644 >>>>> --- a/include/uapi/linux/rtnetlink.h >>>>> +++ b/include/uapi/linux/rtnetlink.h >>>>> @@ -150,6 +150,12 @@ enum { >>>>> RTM_NEWCACHEREPORT = 96, >>>>> #define RTM_NEWCACHEREPORT RTM_NEWCACHEREPORT >>>>> >>>>> + RTM_NEWBLOCK = 100, >>>>> +#define RTM_NEWBLOCK RTM_NEWBLOCK >>>>> + RTM_DELBLOCK, >>>>> +#define RTM_DELBLOCK RTM_DELBLOCK >>>>> + RTM_GETBLOCK, >>>>> +#define RTM_GETBLOCK RTM_GETBLOCK >>>>> __RTM_MAX, >>>>> #define RTM_MAX (((__RTM_MAX + 3) & ~3) - 1) >>>>> }; >>>>> diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c >>>>> index d687e58..14e4f20 100644 >>>>> --- a/net/sched/cls_api.c >>>>> +++ b/net/sched/cls_api.c >>>>> @@ -1553,6 +1553,69 @@ int tc_setup_cb_call(struct tcf_block *block, struct tcf_exts *exts, >>>>> } >>>>> EXPORT_SYMBOL(tc_setup_cb_call); >>>>> >>>>> +static int block_notify_fill(struct net *net, struct sk_buff *skb, >>>>> + struct tcf_block *block, u32 portid, u32 seq, >>>>> + u16 flags, int event) >>>>> +{ >>>>> + struct nlmsghdr *nlh; >>>>> + struct tcmsg *tcm; >>>>> + >>>>> + nlh = nlmsg_put(skb, portid, seq, event, sizeof(*tcm), flags); >>>>> + if (!nlh) >>>>> + return -EMSGSIZE; >>>>> + tcm = nlmsg_data(nlh); >>>>> + memset(tcm, 0, sizeof(*tcm)); >>>>> + tcm->tcm_family = AF_UNSPEC; >>>>> + tcm->tcm_ifindex = TCM_IFINDEX_MAGIC_BLOCK; >>>>> + tcm->tcm_block_index = block->index; >>>>> + return 0; >>>>> +} >>>> >>>> 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?