Thread (37 messages) 37 messages, 5 authors, 2020-09-10

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

From: Jiri Pirko <jiri@resnulli.us>
Date: 2020-09-10 06:52:14
Also in: lkml

Wed, Sep 09, 2020 at 03:27:19PM CEST, moshe@nvidia.com wrote:
On 9/7/2020 8:58 PM, Jakub Kicinski wrote:
quoted
On Mon, 7 Sep 2020 16:46:01 +0300 Moshe Shemesh wrote:
quoted
quoted
In that sense I don't like --live because it doesn't really say much.
AFAIU it means 1) no link flap; 2) < 2 sec datapath downtime; 3) no
configuration is lost in kernel or device (including netdev config,
link config, flow rules, counters etc.). I was hoping at least the
documentation in patch 14 would be more precise.
Actually, while writing "no-reset" or "live-patching" I meant also no
downtime at all and nothing resets (config, rules ... anything), that
fits mlx5 live-patching.

However, to make it more generic,  I can allow few seconds downtime and
add similar constrains as you mentioned here to "no-reset". I will add
that to the documentation patch.
Oh! If your device supports no downtime and packet loss at all that's
great. You don't have to weaken the definition now, whoever needs a
weaker definition can add a different constraint level later, no?

Yes, but if we are thinking there will be more levels, maybe the flag
"--live" or "--no_reset" is less extendable, we may need new attr. I mean
should I have uAPI command line like:

$ devlink dev reload DEV [ netns { PID | NAME | ID } ] [ action {
driver_reinit | fw_activate } [ limit_level  no_reset ] ]
Sounds fine.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help