Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH net-next v5 13/22] ethtool: provide driver/device
 information in GET_INFO request
To:     Michal Kubecek <mkubecek@suse.cz>, Jiri Pirko <jiri@resnulli.us>
Cc:     David Miller <davem@davemloft.net>, netdev@vger.kernel.org,
        Jakub Kicinski <jakub.kicinski@netronome.com>,
        Andrew Lunn <andrew@lunn.ch>,
        John Linville <linville@tuxdriver.com>,
        Stephen Hemminger <stephen@networkplumber.org>,
        linux-kernel@vger.kernel.org
References: <cover.1553532199.git.mkubecek@suse.cz>
 <b7aea4b2642b2fe6f12cfb843a03154f584f3bf6.1553532199.git.mkubecek@suse.cz>
 <20190327201411.GH14297@nanopsycho> <20190327222554.GV26076@unicorn.suse.cz>
From:   Florian Fainelli <f.fainelli@gmail.com>
Openpgp: preference=signencrypt
Message-ID: <6e5fd327-d2ba-1b8d-44ce-fa975c73bffb@gmail.com>
Date:   Wed, 27 Mar 2019 19:30:09 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <20190327222554.GV26076@unicorn.suse.cz>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 3/27/2019 3:25 PM, Michal Kubecek wrote:
> On Wed, Mar 27, 2019 at 09:14:11PM +0100, Jiri Pirko wrote:
>> Mon, Mar 25, 2019 at 06:08:33PM CET, mkubecek@suse.cz wrote:
>>> +
>>> +Kernel response contents:
>>> +
>>> +    ETHA_INFO_DEV		(nested)	device identification
>>> +    ETHA_INFO_DRVINFO		(nested)	driver information
>>> +        ETHA_DRVINFO_DRIVER		(string)	driver name
>>> +        ETHA_DRVINFO_FWVERSION		(string)	firmware version
>>> +        ETHA_DRVINFO_BUSINFO		(string)	device bus address
>>> +        ETHA_DRVINFO_EROM_VER		(string)	expansion ROM version
>>
>> These are already very nicely supported in devlink. No need to duplicate
>> here.
> 
> They are supported by devlink as an interface. But devlink itself is
> only supported by few NIC drivers at the moment:
> 
> mike@unicorn:~/work/git/net-next> grep -r devlink_ops drivers/net/

You might want to include net/ in your list too.

> drivers/net/ethernet/mellanox/mlx4/main.c:static const struct devlink_ops mlx4_devlink_ops = {
> drivers/net/ethernet/mellanox/mlx4/main.c:      devlink = devlink_alloc(&mlx4_devlink_ops, sizeof(*priv));
> drivers/net/ethernet/mellanox/mlxsw/core.c:static const struct devlink_ops mlxsw_devlink_ops = {
> drivers/net/ethernet/mellanox/mlxsw/core.c:             devlink = devlink_alloc(&mlxsw_devlink_ops, alloc_size);
> drivers/net/ethernet/mellanox/mlx5/core/main.c:static const struct devlink_ops mlx5_devlink_ops = {
> drivers/net/ethernet/mellanox/mlx5/core/main.c: devlink = devlink_alloc(&mlx5_devlink_ops, sizeof(*dev));
> drivers/net/ethernet/cavium/liquidio/lio_main.c:static const struct devlink_ops liquidio_devlink_ops = {
> drivers/net/ethernet/cavium/liquidio/lio_main.c:        devlink = devlink_alloc(&liquidio_devlink_ops,
> drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c:static const struct devlink_ops bnxt_dl_ops = {
> drivers/net/ethernet/netronome/nfp/nfp_main.c:  devlink = devlink_alloc(&nfp_devlink_ops, sizeof(*pf));
> drivers/net/ethernet/netronome/nfp/nfp_main.h:extern const struct devlink_ops nfp_devlink_ops;
> drivers/net/ethernet/netronome/nfp/nfp_devlink.c:const struct devlink_ops nfp_devlink_ops = {
> drivers/net/netdevsim/devlink.c:static const struct devlink_ops nsim_devlink_ops = {
> drivers/net/netdevsim/devlink.c:        devlink = devlink_alloc(&nsim_devlink_ops, 0);
> 
> That's 6 drivers from 4 vendors (if I don't count netdevsim). And I did
> not check if all of them do actually provide the information shown
> above. On the other hand:
> 
> mike@unicorn:~/work/git/net-next> egrep -r '\.get_drvinfo' drivers/net/ | wc -l
> 240
> 
> Some of these 240 lines assign the same handler but not enough to make
> me optimistic about being able to implement "ethtool -i <dev>" using
> devlink interface in near future (say few months or one year).
> 
> I'm all for implementing new features which are are related to physical
> device (ASIC) rather than network interface only in devlink (at the
> level of kernel-userspace interface). But for features already provided
> by ethtool (userspace utility) I can't help seeing the state of devlink
> support in NIC drivers as a serious blocker.

Can't we just interrogate devlink first if there is a devlink <->
net_device mapping and fallback to ethtool_ops::get_drvinfo if that did
not work? Maybe issue a (rate-limited) warning "use devlink instead".
-- 
Florian