From: Moshe Shemesh <firstname.lastname@example.org> To: Jakub Kicinski <email@example.com> Cc: "David S. Miller" <firstname.lastname@example.org>, Jiri Pirko <email@example.com>, Vasundhara Volam <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org Subject: Re: [PATCH net-next RFC 02/13] devlink: Add reload levels data to dev get Date: Thu, 30 Jul 2020 15:05:06 +0300 Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> On 7/30/2020 12:11 AM, Jakub Kicinski wrote: > On Wed, 29 Jul 2020 17:37:41 +0300 Moshe Shemesh wrote: >>> The fact that the driver supports fw_live_patch, does not necessarily >>> mean that the currently running FW can be live upgraded to the >>> currently flashed one, right? >> That's correct, though the feature is supported, the firmware gap may >> not be suitable for live_patch. >> >> The user will be noted accordingly by extack message. > That's kinda late, because use may have paid the cost of migrating the > workload or otherwise taking precautions - and if live reset fails all > this work is wasted. > > While the device most likely knows upfront whether it can be live reset > or not, otherwise I don't see how it could reject the reset reliably. The device knows if the new FW can be updated by live-patch or need reset once the new version is stored and it so it can check the gaps. So once the new FW is stored I can query if it is a change that can do by live_patch or need full fw_reset. >>> This interface does not appear to be optimal for the purpose. >>> >>> Again, documentation of what can be lost (in terms of configuration and >>> features) upon upgrade is missing. >> I will clarify in documentation. On live_patch nothing should be lost or >> re-initialized, that's the "live" thing. > Okay, so FW upgrade cannot be allowed when it'd mean the device gets > de-featured? Also no link loss, correct? What's the expected length of > traffic interruption (order of magnitude)? That's different between fw_live_patch and fw_reset, that's why I see it as different level. The live_patch is totally live, no link loss, no data interruption at all. But when the firmware gap for upgrade is not suitable for live patch, the user can choose to do full fw reset, that can include link loss (depends on device) for few seconds and some configuration which is not saved by the driver or was not configured through the driver (some other tool) need to re-configure.
next prev parent reply index Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-27 11:02 [PATCH net-next RFC 00/13] Add devlink reload level option Moshe Shemesh 2020-07-27 11:02 ` [PATCH net-next RFC 01/13] devlink: Add reload level option to devlink reload command Moshe Shemesh 2020-07-28 0:58 ` Jakub Kicinski 2020-07-28 13:58 ` Jiri Pirko 2020-07-28 16:47 ` Jacob Keller 2020-07-28 18:44 ` Jakub Kicinski 2020-07-28 19:18 ` Jacob Keller 2020-07-28 20:06 ` Jakub Kicinski 2020-07-29 14:54 ` Moshe Shemesh 2020-07-29 21:07 ` Jakub Kicinski 2020-07-30 12:30 ` Moshe Shemesh 2020-07-30 23:11 ` Jakub Kicinski 2020-08-01 21:32 ` Moshe Shemesh 2020-08-03 14:14 ` Jiri Pirko 2020-08-03 20:57 ` Jakub Kicinski 2020-08-04 10:04 ` Jiri Pirko 2020-08-04 20:39 ` Jakub Kicinski 2020-08-05 11:02 ` Jiri Pirko 2020-08-06 18:25 ` Jakub Kicinski 2020-08-06 22:56 ` Jacob Keller 2020-08-09 13:21 ` Moshe Shemesh 2020-08-10 16:53 ` Jakub Kicinski 2020-08-10 17:09 ` Jacob Keller 2020-08-10 18:17 ` Jakub Kicinski 2020-08-11 5:46 ` Jiri Pirko 2020-07-27 11:02 ` [PATCH net-next RFC 02/13] devlink: Add reload levels data to dev get Moshe Shemesh 2020-07-28 0:58 ` Jakub Kicinski 2020-07-29 14:37 ` Moshe Shemesh 2020-07-29 21:11 ` Jakub Kicinski 2020-07-30 12:05 ` Moshe Shemesh [this message] 2020-07-27 11:02 ` [PATCH net-next RFC 03/13] net/mlx5: Add functions to set/query MFRL register Moshe Shemesh 2020-07-27 11:02 ` [PATCH net-next RFC 04/13] net/mlx5: Set cap for pci sync for fw update event Moshe Shemesh 2020-07-27 11:02 ` [PATCH net-next RFC 05/13] net/mlx5: Handle sync reset request event Moshe Shemesh 2020-07-27 11:02 ` [PATCH net-next RFC 06/13] net/mlx5: Handle sync reset now event Moshe Shemesh 2020-07-27 11:02 ` [PATCH net-next RFC 07/13] net/mlx5: Handle sync reset abort event Moshe Shemesh 2020-07-27 11:02 ` [PATCH net-next RFC 08/13] net/mlx5: Add support for devlink reload level fw reset Moshe Shemesh 2020-07-27 11:02 ` [PATCH net-next RFC 09/13] devlink: Add enable_remote_dev_reset generic parameter Moshe Shemesh 2020-07-28 0:59 ` Jakub Kicinski 2020-07-29 14:42 ` Moshe Shemesh 2020-07-29 20:57 ` Jakub Kicinski 2020-07-30 12:08 ` Moshe Shemesh 2020-07-27 11:02 ` [PATCH net-next RFC 10/13] net/mlx5: Add devlink param enable_remote_dev_reset support Moshe Shemesh 2020-07-28 0:59 ` Jakub Kicinski 2020-07-27 11:02 ` [PATCH net-next RFC 11/13] net/mlx5: Add support for fw live patch event Moshe Shemesh 2020-07-27 11:02 ` [PATCH net-next RFC 12/13] net/mlx5: Add support for devlink reload level live patch Moshe Shemesh 2020-07-27 11:02 ` [PATCH net-next RFC 13/13] devlink: Add Documentation/networking/devlink/devlink-reload.rst Moshe Shemesh 2020-07-28 5:25 ` [PATCH net-next RFC 00/13] Add devlink reload level option Vasundhara Volam 2020-07-28 16:43 ` Jacob Keller 2020-08-03 10:24 ` Vasundhara Volam 2020-08-03 12:17 ` Moshe Shemesh 2020-08-03 12:47 ` Vasundhara Volam 2020-08-03 13:52 ` Moshe Shemesh 2020-08-04 10:13 ` Vasundhara Volam 2020-08-05 6:32 ` Moshe Shemesh 2020-08-05 6:55 ` Vasundhara Volam 2020-08-05 8:20 ` Moshe Shemesh 2020-08-12 9:34 ` Vasundhara Volam 2020-07-28 16:37 ` Jacob Keller
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ email@example.com public-inbox-index lkml Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git