Re: [PATCH net-next RFC v2 01/13] devlink: Add reload action option to devlink reload command

From: Moshe Shemesh
Date: Tue Aug 18 2020 - 05:06:29 EST



On 8/17/2020 7:16 PM, Jakub Kicinski wrote:

On Mon, 17 Aug 2020 12:37:40 +0300 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.
See, this is why I wanted to keep --live as a separate option.
Normally the driver is okay to satisfy more actions than requested,
e.g. activate FW even if only driver_reinit was requested.

fw_live_patch does not have this semantics, it explicitly requires
driver to not impact connectivity much. No "can do more resets than
requested" here. Hence the --live part would be better off as a
separate argument (at least in uAPI, the in-kernel interface we can
change later if needed).


Yes, it does have a different semantics, kind of no reset allowed.

On the other hand, it is not related to driver_reinit, only fw_activate.

So the uAPI should be:

    devlink dev reload DEV [ netns { PID | NAME | ID } ] [ action { driver_reinit | fw_activate [--live] } ]

Or maybe better than "live" say explicitly "no reset":

    devlink dev reload DEV [ netns { PID | NAME | ID } ] [ action { driver_reinit | fw_activate [--no_reset] } ]


Reload actions supported are:
driver_reinit: driver entities re-initialization, applying devlink-param
and devlink-resource values.
fw_activate: firmware activate.
fw_live_patch: firmware live patching.