Messages in this thread | | | Subject | Re: [PATCH net-next RFC 00/13] Add devlink reload level option | From | Jacob Keller <> | Date | Tue, 28 Jul 2020 09:43:57 -0700 |
| |
On 7/27/2020 10:25 PM, Vasundhara Volam wrote: > On Mon, Jul 27, 2020 at 4:36 PM Moshe Shemesh <moshe@mellanox.com> wrote: >> >> Introduce new option on devlink reload API to enable the user to select the >> reload level required. Complete support for all levels in mlx5. >> The following reload levels are supported: >> driver: Driver entities re-instantiation only. >> fw_reset: Firmware reset and driver entities re-instantiation. > The Name is a little confusing. I think it should be renamed to > fw_live_reset (in which both firmware and driver entities are > re-instantiated). For only fw_reset, the driver should not undergo > reset (it requires a driver reload for firmware to undergo reset). >
So, I think the differentiation here is that "live_patch" doesn't reset anything.
>> fw_live_patch: Firmware live patching only. > This level is not clear. Is this similar to flashing?? > > Also I have a basic query. The reload command is split into > reload_up/reload_down handlers (Please correct me if this behaviour is > changed with this patchset). What if the vendor specific driver does > not support up/down and needs only a single handler to fire a firmware > reset or firmware live reset command?
In the "reload_down" handler, they would trigger the appropriate reset, and quiesce anything that needs to be done. Then on reload up, it would restore and bring up anything quiesced in the first stage.
| |