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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 10 Jul 2020 11:16:51 -0700
From:   Jacob Keller <jacob.e.keller@...el.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>, moshe@...lanox.com
Subject: Re: [RFC v2 net-next] devlink: Add reset subcommand.



On 7/1/2020 2:47 AM, Jiri Pirko 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.
> 

Right. We should re-use the component names from devlink dev info here
(just as we do in devlink dev 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.
> 
If we add this to reload I'm not sure it's necessary. The devlink
application could be configured to request a reload after the update
completes.

> 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.

Have patches for this been posted at all?

> 
> 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.
> 

Yes.