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

From: Moshe Shemesh
Date: Wed Aug 19 2020 - 10:23:47 EST



On 8/19/2020 3:46 PM, Jiri Pirko wrote:
Wed, Aug 19, 2020 at 02:18:22PM CEST, moshe@xxxxxxxxxx wrote:
On 8/19/2020 3:10 AM, Jakub Kicinski wrote:
On Tue, 18 Aug 2020 12:10:36 +0300 Moshe Shemesh wrote:
On 8/17/2020 7:36 PM, Jiri Pirko wrote:
Mon, Aug 17, 2020 at 11:37:40AM CEST, moshe@xxxxxxxxxxxx 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
Sounds reasonable. I think it would be good to indicate that though. Not
sure how...
Maybe counters on the actions done ? Actually such counters can be
useful on debug, knowing what reloads we had since driver was up.
Wouldn't we need to know all types of reset of drivers may do?

Right, we can't tell all reset types driver may have, but we can tell which
reload actions were done.

I think documenting this clearly should be sufficient.

A reset counter for the _requested_ reset type (fully maintained by
core), however - that may be useful. The question "why did this NIC
reset itself / why did the link just flap" comes up repeatedly.

I will add counters on which reload were done. reload_down()/up() can return
which actions were actually done and devlink will show counters.
Why a counter? Just return what was done over netlink reply.


Such counters can be useful for debugging, telling which reload actions were done on this dev from the point it was up.