netdev - Re: [PATCH v3 net-next 0/6] bnxt_en: Add 'enable_live_dev_reset' and 'allow_live_dev

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 1 Jun 2020 16:24:16 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Vasundhara Volam <vasundhara-v.volam@...adcom.com>
Cc:     Jiri Pirko <jiri@...nulli.us>, David Miller <davem@...emloft.net>,
        Netdev <netdev@...r.kernel.org>,
        Michael Chan <michael.chan@...adcom.com>
Subject: Re: [PATCH v3 net-next 0/6] bnxt_en: Add 'enable_live_dev_reset'
 and 'allow_live_dev_reset' generic devlink params.

On Mon, 1 Jun 2020 21:01:42 +0530 Vasundhara Volam wrote:
> > I think that the legacy ethtool should stick with the "ordinary fw reset",
> > becase that is what user expects. You should add an attribute to
> > "devlink dev reload" to trigger the "live fw reset"  
> 
> Okay.
> 
> I am planning to add a type field with "driver-only | fw-reset |
> live-fw-reset | live-fw-patch" to "devlink dev reload" command.
> 
> driver-only - Resets host driver instance of the 'devlink dev'
> (current behaviour). This will be default, if the user does not
> provide the type option.
> fw-reset - Initiate the reset command for the currently running
> firmware and wait for the driver reload for completing the reset.
> (This is similar to the legacy "ethtool --reset all" command).
> live-fw-reset - Resets the currently running firmware and driver entities.
> live-fw-patch - Loads the currently pending flashed firmware and
> reloads all driver entities. If no pending flashed firmware, resets
> currently loaded firmware.

FWIW I'd prefer to extend the ethtool semantics. Ethtool reset has two
reset "depths" already - single port, entire adapter, we could just add
"entire sled" here. IOW we'd have reset which can affect only given
port, then reset which can affect multiple ports, and reset which may
affect multiple systems.

The mechanism of the reset and whether old or new version of FW is
activated is a detail, which I believe will be entirely uninteresting 
to the user. Whether other systems or ports are affected is _very_
important, OTOH.