From: Moshe Shemesh <moshe@nvidia.com>
To: "David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Parav Pandit <parav@nvidia.com>
Cc: Jiri Pirko <jiri@nvidia.com>, Saeed Mahameed <saeedm@nvidia.com>,
<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
Moshe Shemesh <moshe@nvidia.com>
Subject: [PATCH net-next v2 0/4] net/mlx5: Introduce devlink param to disable SF aux dev probe
Date: Fri, 11 Feb 2022 11:20:17 +0200 [thread overview]
Message-ID: <1644571221-237302-1-git-send-email-moshe@nvidia.com> (raw)
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
next reply other threads:[~2022-02-11 9:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-11 9:20 Moshe Shemesh [this message]
2022-02-11 9:20 ` [PATCH net-next v2 1/4] net/mlx5: Split function_setup() to enable and open functions Moshe Shemesh
2022-02-11 9:20 ` [PATCH net-next v2 2/4] net/mlx5: Delete redundant default assignment of runtime devlink params Moshe Shemesh
2022-02-11 9:20 ` [PATCH net-next v2 3/4] devlink: Add new "enable_sfs_aux_devs" generic device param Moshe Shemesh
2022-02-11 9:20 ` [PATCH net-next v2 4/4] net/mlx5: Support enable_sfs_aux_devs devlink param Moshe Shemesh
2022-02-12 1:12 ` [PATCH net-next v2 0/4] net/mlx5: Introduce devlink param to disable SF aux dev probe Jakub Kicinski
2022-02-14 14:45 ` Parav Pandit
2022-02-24 3:44 ` Parav Pandit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1644571221-237302-1-git-send-email-moshe@nvidia.com \
--to=moshe@nvidia.com \
--cc=davem@davemloft.net \
--cc=jiri@nvidia.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=parav@nvidia.com \
--cc=saeedm@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).