netdev - Re: [RFC v2 net-next] devlink: Add reset subcommand.

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <40b71e67-d83e-9c3f-be8a-1c75b8c860cc@mellanox.com>
Date:   Wed, 22 Jul 2020 22:32:36 +0300
From:   Moshe Shemesh <moshe@...lanox.com>
To:     Jiri Pirko <jiri@...nulli.us>,
        Vasundhara Volam <vasundhara-v.volam@...adcom.com>
Cc:     David Miller <davem@...emloft.net>,
        Netdev <netdev@...r.kernel.org>,
        Michael Chan <michael.chan@...adcom.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Jiri Pirko <jiri@...lanox.com>,
        Michal Kubecek <mkubecek@...e.cz>
Subject: Re: [RFC v2 net-next] devlink: Add reset subcommand.


On 7/21/2020 3:19 PM, Jiri Pirko wrote:
> Tue, Jul 21, 2020 at 11:51:21AM CEST, vasundhara-v.volam@...adcom.com wrote:
>> On Wed, Jul 1, 2020 at 3:17 PM Jiri Pirko <jiri@...nulli.us> wrote:
>>> Wed, Jul 01, 2020 at 11:25:50AM CEST, vasundhara-v.volam@...adcom.com wrote:
>>>> On Wed, Jul 1, 2020 at 11:21 AM Jiri Pirko <jiri@...nulli.us> wrote:
>>>>> Tue, Jun 30, 2020 at 05:15:18PM CEST, vasundhara-v.volam@...adcom.com wrote:
>>>>>> On Tue, Jun 30, 2020 at 6:23 PM Jiri Pirko <jiri@...nulli.us> wrote:
>>>>>>> Tue, Jun 30, 2020 at 01:34:06PM CEST, vasundhara-v.volam@...adcom.com wrote:
>>>>>>>> Advanced NICs support live reset of some of the hardware
>>>>>>>> components, that resets the device immediately with all the
>>>>>>>> host drivers loaded.
>>>>>>>>
>>>>>>>> Add devlink reset subcommand to support live and deferred modes
>>>>>>>> of reset. It allows to reset the hardware components of the
>>>>>>>> entire device and supports the following fields:
>>>>>>>>
>>>>>>>> component:
>>>>>>>> ----------
>>>>>>>> 1. MGMT : Management processor.
>>>>>>>> 2. DMA : DMA engine.
>>>>>>>> 3. RAM : RAM shared between multiple components.
>>>>>>>> 4. AP : Application processor.
>>>>>>>> 5. ROCE : RoCE management processor.
>>>>>>>> 6. All : All possible components.
>>>>>>>>
>>>>>>>> Drivers are allowed to reset only a subset of requested components.
>>>>>>> I don't understand why would user ever want to do this. He does not care
>>>>>>> about some magic hw entities. He just expects the hw to work. I don't
>>>>>>> undestand the purpose of exposing something like this. Could you please
>>>>>>> explain in details? Thanks!
>>>>>>>
>>>>>> If a user requests multiple components and if the driver is only able
>>>>>> to honor a subset, the driver will return the components unset which
>>>>>> it is able to reset.  For example, if a user requests MGMT, RAM and
>>>>>> ROCE components to be reset and driver resets only MGMT and ROCE.
>>>>>> Driver will unset only MGMT and ROCE bits and notifies the user that
>>>>>> RAM is not reset.
>>>>>>
>>>>>> This will be useful for drivers to reset only a subset of components
>>>>>> requested instead of returning error or silently doing only a subset
>>>>>> of components.
>>>>>>
>>>>>> Also, this will be helpful as user will not know the components
>>>>>> supported by different vendors.
>>>>> Your reply does not seem to be related to my question :/
>>>> I thought that you were referring to: "Drivers are allowed to reset
>>>> only a subset of requested components."
>>>>
>>>> or were you referring to components? If yes, the user can select the
>>>> components that he wants to go for reset. This will be useful in the
>>>> case where, if the user flashed only a certain component and he wants
>>>> to reset that particular component. For example, in the case of SOC
>>>> there are 2 components: MGMT and AP. If a user flashes only
>>>> application processor, he can choose to reset only application
>>>> processor.
>>> We already have notion of "a component" in "devlink dev flash". I think
>>> that the reset component name should be in-sync with the flash.
>>>
>>> Thinking about it a bit more, we can extend the flash command by "reset"
>>> attribute that would indicate use wants to do flash&reset right away.
>>>
>>> Also, thinking how this all aligns with "devlink dev reload" which we
>>> currently have. The purpose of it is to re-instantiate driver instances,
>>> but in case of mlxsw it means friggering FW reset as well.
>>>
>>> Moshe (cced) is now working on "devlink dev reload" extension that would
>>> allow user to ask for a certain level of reload: driver instances only,
>>> fw reset too, live fw patching, etc.
>>>
>>> Not sure how this overlaps with your intentions. I think it would be
>>> great to see Moshe's RFC here as well so we can aligh the efforts.
>> Are the patches posted yet?
> I don't think so.
>
> Moshe?


Not yet, still in internal review.

If won't pass by EOW I will send part of it as RFC.