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

[Jacob Keller <jacob.e.keller@intel.com>]

On 7/1/2020 2:47 AM, Jiri Pirko wrote:
> Wed, Jul 01, 2020 at 11:25:50AM CEST, vasundhara-v.volam@broadcom.com wrote:
>> On Wed, Jul 1, 2020 at 11:21 AM Jiri Pirko <jiri@resnulli.us> wrote:
>>>
>>> Tue, Jun 30, 2020 at 05:15:18PM CEST, vasundhara-v.volam@broadcom.com wrote:
>>>> On Tue, Jun 30, 2020 at 6:23 PM Jiri Pirko <jiri@resnulli.us> wrote:
>>>>>
>>>>> Tue, Jun 30, 2020 at 01:34:06PM CEST, vasundhara-v.volam@broadcom.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.