[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4e4e389c-704f-84f9-e69c-57ce5e9e2df7@intel.com>
Date: Mon, 5 Oct 2020 11:39:32 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: Moshe Shemesh <moshe@...lanox.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>, Jiri Pirko <jiri@...dia.com>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 02/16] devlink: Add reload action option to
devlink reload command
On 10/1/2020 6:59 AM, Moshe Shemesh wrote:
> Add devlink reload action to allow the user to request a specific reload
> action. The action parameter is optional, if not specified then devlink
> driver re-init action is used (backward compatible).
> Note that when required to do firmware activation some drivers may need
> to reload the driver. On the other hand some drivers may need to reset
> the firmware to reinitialize the driver entities. Therefore, the devlink
> reload command returns the actions which were actually performed.
> Reload actions supported are:
> driver_reinit: driver entities re-initialization, applying devlink-param
> and devlink-resource values.
> fw_activate: firmware activate.
>
> command examples:
> $devlink dev reload pci/0000:82:00.0 action driver_reinit
> reload_actions_performed:
> driver_reinit
>
> $devlink dev reload pci/0000:82:00.0 action fw_activate
> reload_actions_performed:
> driver_reinit fw_activate
>
> Signed-off-by: Moshe Shemesh <moshe@...lanox.com>
Looks straight forward.
Reviewed-by: Jacob Keller <jacob.e.keller@...el.com>
> ---
> RFCv5 -> v1:
> - Rename supported_reload_actions to reload_actions.
> - Rename devlink_nl_reload_actions_performed_fill() to
> devlink_nl_reload_actions_performed_snd() and add genlmsg_reply() to it
> - Actions_performed sent to user space as a mask
> - Driver can initialize actions_performed before done as devlink ignores
> in case of failure
> - Use nla_poilcy range validation and remove the range check in
> devlink_nl_cmd_reload
> RFCv4 -> RFCv5:
> - Always pass actions_performed to unload_up() instead of checking in
> each driver
> - Verify returned actions_performed includes the requested action
> - Changed devlink_reload_actions_verify(devlink) to get ops
> - Changed devlink_reload_actions_verify() to return bool and rename to
> devlink_reload_actions_valid()
> - Only generate the reply if request uses new attributes
> RFCv3 -> RFCv4:
> - Removed fw_activate_no_reset as an action (next patch adds limit
> levels instead).
> - Renamed actions_done to actions_performed
> RFCv2 -> RFCv3:
> - Replace fw_live_patch action by fw_activate_no_reset
> - Devlink reload returns the actions done over netlink reply
> RFCv1 -> RFCv2:
> - Instead of reload levels driver,fw_reset,fw_live_patch have reload
> actions driver_reinit,fw_activate,fw_live_patch
> - Remove driver default level, the action driver_reinit is the default
> action for all drivers
> ---
> drivers/net/ethernet/mellanox/mlx4/main.c | 7 +-
> .../net/ethernet/mellanox/mlx5/core/devlink.c | 7 +-
> drivers/net/ethernet/mellanox/mlxsw/core.c | 11 +-
> drivers/net/netdevsim/dev.c | 8 +-
> include/net/devlink.h | 7 +-
> include/uapi/linux/devlink.h | 18 ++++
> net/core/devlink.c | 101 ++++++++++++++++--
> 7 files changed, 139 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
> index 70cf24ba71e4..a44d8b733db3 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/main.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/main.c
> @@ -3946,6 +3946,7 @@ static int mlx4_restart_one_up(struct pci_dev *pdev, bool reload,
> struct devlink *devlink);
>
> static int mlx4_devlink_reload_down(struct devlink *devlink, bool netns_change,
> + enum devlink_reload_action action,
> struct netlink_ext_ack *extack)
> {
I might have opted to convert reload_down to take a structure of
parameters, given that we're about to add 2 parameters. Not really that
significant either way.
Powered by blists - more mailing lists