From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jiri Pirko Subject: Re: [patch net-next v7 08/13] net: sched: add rt netlink message type for block get Date: Thu, 11 Jan 2018 12:11:47 +0100 Message-ID: <20180111111147.GD2053@nanopsycho.orion> References: <20180109140731.1022-1-jiri@resnulli.us> <20180109140731.1022-9-jiri@resnulli.us> <9baf8774-cd25-4b85-fc29-a60a2972adf6@gmail.com> <20180111093710.GA2053@nanopsycho.orion> 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-wm0-f65.google.com ([74.125.82.65]:46018 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932861AbeAKLLt (ORCPT ); Thu, 11 Jan 2018 06:11:49 -0500 Received: by mail-wm0-f65.google.com with SMTP id i186so4686835wmi.4 for ; Thu, 11 Jan 2018 03:11:48 -0800 (PST) Content-Disposition: inline In-Reply-To: <20180111093710.GA2053@nanopsycho.orion> Sender: netdev-owner@vger.kernel.org List-ID: Thu, Jan 11, 2018 at 10:37:10AM CET, jiri@resnulli.us wrote: >Wed, Jan 10, 2018 at 05:48:09PM CET, dsahern@gmail.com wrote: >>On 1/9/18 7:07 AM, Jiri Pirko wrote: >>> diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h >>> index 9c026d9..038cde7 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) >>> }; >> >>Seems like this is creating an inconsistency. RTM_GETBLOCK is used to >>dump the set of shared blocks, but RTM_NEWBLOCK / RTM_DELBLOCK are not >>used to create / delete one. > >Why is it a problem? RTM_NEWBLOCK is used as a reply for RTM_GETBLOCK. >I plan to have block notifications as a follow-up, there the RTM_GETBLOCK I mean RTM_NEWBLOCK and RTM_DELBLOCK of couse. >and RTM_DELBLOCK will be used. The fact the user cannot create and >delete block explicitly is no problem in my opinion. The block creation >and deletion is done according to usage of qdiscs.