On Wed, Sep 9, 2020 at 10:51 PM Moshe Shemesh [off-list ref] 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 ] ]

This sounds good. As coming to our device, user can issue

$devlink dev reload DEV action fw_activate

which resets both firmware and driver entities to activate the new
firmware (either pending flashed firmware or reset current firmware).

Thanks for the patch series.