From mboxrd@z Thu Jan  1 00:00:00 1970
From: Arkadi Sharshevsky <arkadis@mellanox.com>
Subject: Re: [patch net-next 02/10] devlink: Add support for resource
 abstraction
Date: Mon, 25 Dec 2017 13:12:07 +0200
Message-ID: <f9db5683-6e0d-bb9e-9adb-2a0a87d95781@mellanox.com>
References: <20171220115821.22171-1-jiri@resnulli.us>
 <20171220115821.22171-3-jiri@resnulli.us>
 <20171220.144358.1892414104907740492.davem@davemloft.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Cc: netdev@vger.kernel.org, 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, ast@kernel.org,
        daniel@iogearbox.net, simon.horman@netronome.com,
        pieter.jansenvanvuuren@netronome.com, john.hurley@netronome.com,
        alexander.h.duyck@intel.com, linville@tuxdriver.com,
        gospo@broadcom.com, steven.lin1@broadcom.com, yuvalm@mellanox.com,
        ogerlitz@mellanox.com, dsa@cumulusnetworks.com,
        roopa@cumulusnetworks.com
To: David Miller <davem@davemloft.net>, jiri@resnulli.us
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-ve1eur01on0061.outbound.protection.outlook.com ([104.47.1.61]:42496
        "EHLO EUR01-VE1-obe.outbound.protection.outlook.com"
        rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP
        id S1752029AbdLYLMW (ORCPT <rfc822;netdev@vger.kernel.org>);
        Mon, 25 Dec 2017 06:12:22 -0500
In-Reply-To: <20171220.144358.1892414104907740492.davem@davemloft.net>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>



On 12/20/2017 09:43 PM, David Miller wrote:
> From: Jiri Pirko <jiri@resnulli.us>
> Date: Wed, 20 Dec 2017 12:58:13 +0100
> 
>> From: Arkadi Sharshevsky <arkadis@mellanox.com>
>>
>> Add support for hardware resource abstraction over devlink. Each resource
>> is identified via id, furthermore it contains information regarding its
>> size and its related sub resources. Each resource can also provide its
>> current occupancy.
>>
>> In some cases the sizes of some resources can be changed, yet for those
>> changes to take place a hot driver reload may be needed. The reload
>> capability will be introduced in the next patch.
>>
>> Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com>
>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> 
> In what units are these sizes?  If it depends upon the resource, it would
> be great to have a way to introspect the units given a resource.
> 

This is problematic. Currently the units are actually double words
(single entry is 64 bit) because this resource is a actually a memory.
So my first thought was adding an enum in UAPI of resource_units

enum resource_units {
	DEVLINK_RESOURCE_UNITS_WORD,
	DEVLINK_RESOURCE_UNITS_DOUBLE_WORD,
	DEVLINK_RESOURCE_UNITS_ITEM, /* this is in order to define some
                                        driver specific stuff*/
        ...
};

But the 'item' is too vague, because for example, we will have the
RIF bank as resource. What unit will it have? rifs? items?

Any inputs on this?


>> +	struct devlink_resource_ops *resource_ops;
> 
> Const?
> 
>> +static inline int
>> +devlink_resource_register(struct devlink *devlink,
>> +			  const char *resource_name,
>> +			  bool top_hierarchy,
>> +			  u64 resource_size,
>> +			  u64 resource_id,
>> +			  u64 parent_resource_id,
>> +			  struct devlink_resource_ops *resource_ops)
> 
> Const for resource_ops?
> 
>> +int devlink_resource_register(struct devlink *devlink,
>> +			      const char *resource_name,
>> +			      bool top_hierarchy,
>> +			      u64 resource_size,
>> +			      u64 resource_id,
>> +			      u64 parent_resource_id,
>> +			      struct devlink_resource_ops *resource_ops)
> 
> Likewise.
>