Messages in this thread | | | Subject | Re: [PATCH net-next RFC 09/13] devlink: Add enable_remote_dev_reset generic parameter | From | Moshe Shemesh <> | Date | Thu, 30 Jul 2020 15:08:42 +0300 |
| |
On 7/29/2020 11:57 PM, Jakub Kicinski wrote: > On Wed, 29 Jul 2020 17:42:12 +0300 Moshe Shemesh wrote: >> On 7/28/2020 3:59 AM, Jakub Kicinski wrote: >>> On Mon, 27 Jul 2020 14:02:29 +0300 Moshe Shemesh wrote: >>>> The enable_remote_dev_reset devlink param flags that the host admin >>>> allows device resets that can be initiated by other hosts. This >>>> parameter is useful for setups where a device is shared by different >>>> hosts, such as multi-host setup. Once the user set this parameter to >>>> false, the driver should NACK any attempt to reset the device while the >>>> driver is loaded. >>>> >>>> Signed-off-by: Moshe Shemesh <moshe@mellanox.com> >>> There needs to be a devlink event generated when reset is triggered >>> (remotely or not). >>> >>> You're also missing failure reasons. Users need to know if the reset >>> request was clearly nacked by some host, not supported, etc. vs >>> unexpected failure. >> I will fix and send extack message to the user accordingly. > I'd suggest the reason codes to be somewhat standard. > > The groups I can think of: > - timeout - device did not respond to the reset request > - device reject - FW or else has nacked the activation req > - host incapable - one of the participating hosts (in MH) is not > capable of handling live activation > - host denied - one of the participating hosts has NACKed > - host timeout - one of the p. hosts did not ack or done the procedure > in time (e.g. has not toggled the link) > - failed reset - the activation itself had failed > - failed reinit - one of p. hosts was not able to cleanly come back up
Sounds good, that seems to cover all options of fw_reset process to fail.
| |