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
| ||
|
Date: Fri, 11 Feb 2022 11:20:17 +0200 From: Moshe Shemesh <moshe@...dia.com> To: "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Parav Pandit <parav@...dia.com> CC: Jiri Pirko <jiri@...dia.com>, Saeed Mahameed <saeedm@...dia.com>, <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>, Moshe Shemesh <moshe@...dia.com> Subject: [PATCH net-next v2 0/4] net/mlx5: Introduce devlink param to disable SF aux dev probe Currently SF device has all the aux devices enabled by default. Once loaded, user who desire to disable some of them need to perform devlink reload. This operation helps to reclaim memory that was not supposed to be used, but the lost time in disabling and enabling again cannot be recovered by this approach[1]. Therefore, introduce a new devlink generic parameter for PCI PF which spawns SF devices. This parameter sets a flag in order to disable all auxiliary devices of the SF. i.e.: All children auxiliary devices of SF for RDMA, eth and vdpa-net are disabled by default and hence no device initialization is done at probe stage. The settings introduced here should suit either if ESW and PF are on same host or not. Example 1: When ESW and SF hosting PF are the same: Disable SF aux dev probe: $ devlink dev param set pci/0000:08:00.0 name enable_sfs_aux_devs \ value false cmode runtime Create SF: $ devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 11 $ devlink port function set pci/0000:08:00.0/32768 \ hw_addr 00:00:00:00:00:11 state active Now depending on the use case, the user can enable specific auxiliary device(s). For example: $ devlink dev param set auxiliary/mlx5_core.sf.1 \ name enable_vnet value true cmode driverinit Afterwards, user needs to reload the SF in order for the SF to come up with the specific configuration: $ devlink dev reload auxiliary/mlx5_core.sf.1 Example2: ESW and PF are on different hosts. Disable SF's children auxiliary device probing for the specified PF on host: $ devlink dev param set pci/0000:04:00.0 name enable_sfs_aux_devs \ value false cmode runtime Create SF on ESW side: $ devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 11 \ controller 1 $ devlink port function set pci/0000:08:00.0/32768 \ hw_addr 00:00:00:00:00:11 state active When SF device appears on the host: $ devlink dev param set auxiliary/mlx5_core.sf.1 \ name enable_vnet value true cmode driverinit $ devlink dev reload auxiliary/mlx5_core.sf.1 changelog: v1->v2: - updated example to make clear SF port and SF device creation PFs - added example when SF port and device creation PFs are on different hosts [1] mlx5 devlink reload is taking about 2 seconds, which means that with 256 SFs we are speaking about ~8.5 minutes. Shay Drory (4): net/mlx5: Split function_setup() to enable and open functions net/mlx5: Delete redundant default assignment of runtime devlink params devlink: Add new "enable_sfs_aux_devs" generic device param net/mlx5: Support enable_sfs_aux_devs devlink param .../networking/devlink/devlink-params.rst | 5 + drivers/net/ethernet/mellanox/mlx5/core/dev.c | 16 ++ .../net/ethernet/mellanox/mlx5/core/devlink.c | 51 ++--- .../net/ethernet/mellanox/mlx5/core/eswitch.c | 3 + .../net/ethernet/mellanox/mlx5/core/health.c | 5 +- .../net/ethernet/mellanox/mlx5/core/main.c | 183 +++++++++++++++--- .../ethernet/mellanox/mlx5/core/mlx5_core.h | 6 + .../mellanox/mlx5/core/sf/dev/driver.c | 13 +- .../ethernet/mellanox/mlx5/core/sf/devlink.c | 40 ++++ .../ethernet/mellanox/mlx5/core/sf/hw_table.c | 7 + .../net/ethernet/mellanox/mlx5/core/sf/priv.h | 2 + include/linux/mlx5/driver.h | 1 + include/net/devlink.h | 4 + net/core/devlink.c | 5 + 14 files changed, 284 insertions(+), 57 deletions(-) -- 2.26.3
Powered by blists - more mailing lists