lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20190328092126.GL14297@nanopsycho> Date: Thu, 28 Mar 2019 10:21:26 +0100 From: Jiri Pirko <jiri@...nulli.us> To: Michal Kubecek <mkubecek@...e.cz> Cc: David Miller <davem@...emloft.net>, netdev@...r.kernel.org, Jakub Kicinski <jakub.kicinski@...ronome.com>, Andrew Lunn <andrew@...n.ch>, Florian Fainelli <f.fainelli@...il.com>, John Linville <linville@...driver.com>, Stephen Hemminger <stephen@...workplumber.org>, linux-kernel@...r.kernel.org Subject: Re: [PATCH net-next v5 13/22] ethtool: provide driver/device information in GET_INFO request Wed, Mar 27, 2019 at 11:25:54PM CET, mkubecek@...e.cz wrote: >On Wed, Mar 27, 2019 at 09:14:11PM +0100, Jiri Pirko wrote: >> Mon, Mar 25, 2019 at 06:08:33PM CET, mkubecek@...e.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@...corn:~/work/git/net-next> grep -r devlink_ops drivers/net/ >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@...corn:~/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. What I'm thinking about at for some time now would be en explicit default devlink and devlink_port registration for every netdev for drivers that does not support devlink themselves. I need to think about it more, but it seems doable. Then we can hang appropriate things there and make the ethtoolnl/devlink separation clear. I believe we need to do it. > >Michal
Powered by blists - more mailing lists