* Re: [question] About triggering a region snapshot through the devlink cmd
@ 2020-01-07 17:33 Keller, Jacob E
[not found] ` <HE1PR0502MB3771BD83B728249E6C21967AC33E0@HE1PR0502MB3771.eurprd05.prod.outlook.com>
0 siblings, 1 reply; 4+ messages in thread
From: Keller, Jacob E @ 2020-01-07 17:33 UTC (permalink / raw)
To: jiri; +Cc: davem, jiri, linuxarm, linyunsheng, netdev, valex
On 2019/9/27 16:13, Jiri Pirko wrote:
> Fri, Sep 27, 2019 at 09:40:47AM CEST, linyunsheng@huawei.com wrote:
>> Hi, Jiri & Alex
>>
>> It seems that a region' snapshot is only created through the
>> driver when some error is detected, for example:
>> mlx4_crdump_collect_fw_health() -> devlink_region_snapshot_create()
>>
>> We want to trigger a region' snapshot creation through devlink
>> cmd, maybe by adding the "devlink region triger", because we want
>> to check some hardware register/state when the driver or the hardware
>> does not detect the error sometimes.
>>
>> Does about "devlink region triger" make sense?
>>
>> If yes, is there plan to implement it? or any suggestion to implement
>> it?
>
> Actually, the plan is co convert mlx4 to "devlink health" api. Mlx5
> already uses that.
>
> You should look into "devlink health".
Hi Jiri,
I agree, the mlx4 firmware dump stuff should use the devlink health API, as it's for error conditions.
I've recently been investigating using devlink regions to expose non-error regions where it really does make sense to "trigger" a snapshot.
The original region commit message indicates that there were plans to support requesting snapshots, and even potentially writing to the region directly.
I wanted to use a region to expose some set of flash/NVM contents. Being able to request a snapshot is essential in this case. I saw that netdevsim does this through a debugfs hook, but that really doesn't make sense to me for a production driver.
It makes sense to me to be able to trigger a region snapshot directly through devlink. Should I spin up some patches to implement it?
Thanks,
Jake
^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <HE1PR0502MB3771BD83B728249E6C21967AC33E0@HE1PR0502MB3771.eurprd05.prod.outlook.com>]
[parent not found: <HE1PR0502MB3771D512C2D23F551EB922F4C33E0@HE1PR0502MB3771.eurprd05.prod.outlook.com>]
* Re: FW: [question] About triggering a region snapshot through the devlink cmd [not found] ` <HE1PR0502MB3771D512C2D23F551EB922F4C33E0@HE1PR0502MB3771.eurprd05.prod.outlook.com> @ 2020-01-08 19:14 ` Jacob Keller 2020-01-09 19:41 ` Jakub Kicinski 0 siblings, 1 reply; 4+ messages in thread From: Jacob Keller @ 2020-01-08 19:14 UTC (permalink / raw) To: Alex Vesker; +Cc: davem, Jiri Pirko, linuxarm, linyunsheng, netdev, Jiri Pirko On 1/8/2020 4:15 AM, Alex Vesker wrote: > I am a biased here but, devlink trigger can be useful... I am not aware > of other alternatives, > devlink health has it`s benefits but it is not devlink region. If you > will decide to implement I can > review the design, if Jiri is ok with the idea. > Sure. I am not quite sure how long it will be till patches are on the list, as I'm currently in the process of implementing devlink support for one of the Intel drivers, and would be using that driver as an example. Actually, come to think of it, I may just implement the region trigger and use netdevsim as the example. That should enable those patches to hit the list sooner than the patches for implementing devlink for the ice driver. I will Cc you for review when I send those patches. Thanks, Jake ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [question] About triggering a region snapshot through the devlink cmd 2020-01-08 19:14 ` FW: " Jacob Keller @ 2020-01-09 19:41 ` Jakub Kicinski 2020-01-09 20:05 ` Jacob Keller 0 siblings, 1 reply; 4+ messages in thread From: Jakub Kicinski @ 2020-01-09 19:41 UTC (permalink / raw) To: Jacob Keller Cc: Alex Vesker, davem, Jiri Pirko, linuxarm, linyunsheng, netdev, Jiri Pirko On Wed, 8 Jan 2020 11:14:38 -0800, Jacob Keller wrote: > On 1/8/2020 4:15 AM, Alex Vesker wrote: > > I am a biased here but, devlink trigger can be useful... I am not aware > > of other alternatives, > > devlink health has it`s benefits but it is not devlink region. If you > > will decide to implement I can > > review the design, if Jiri is ok with the idea. > > > > Sure. I am not quite sure how long it will be till patches are on the > list, as I'm currently in the process of implementing devlink support > for one of the Intel drivers, and would be using that driver as an example. > > Actually, come to think of it, I may just implement the region trigger > and use netdevsim as the example. That should enable those patches to > hit the list sooner than the patches for implementing devlink for the > ice driver. Just to be clear - you mean implement triggering the dump over netlink? FWIW that seems fairly reasonable to me, but please do explain the use case clearly in the patches. netdevsim is a driver mock up, and debugfs is its control interface. The trigger there is to simulate an async device error, this trigger should not be used as example or justification for anything real driver may need. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [question] About triggering a region snapshot through the devlink cmd 2020-01-09 19:41 ` Jakub Kicinski @ 2020-01-09 20:05 ` Jacob Keller 0 siblings, 0 replies; 4+ messages in thread From: Jacob Keller @ 2020-01-09 20:05 UTC (permalink / raw) To: Jakub Kicinski Cc: Alex Vesker, davem, Jiri Pirko, linuxarm, linyunsheng, netdev, Jiri Pirko On 1/9/2020 11:41 AM, Jakub Kicinski wrote: > On Wed, 8 Jan 2020 11:14:38 -0800, Jacob Keller wrote: >> On 1/8/2020 4:15 AM, Alex Vesker wrote: >>> I am a biased here but, devlink trigger can be useful... I am not aware >>> of other alternatives, >>> devlink health has it`s benefits but it is not devlink region. If you >>> will decide to implement I can >>> review the design, if Jiri is ok with the idea. >>> >> >> Sure. I am not quite sure how long it will be till patches are on the >> list, as I'm currently in the process of implementing devlink support >> for one of the Intel drivers, and would be using that driver as an example. >> >> Actually, come to think of it, I may just implement the region trigger >> and use netdevsim as the example. That should enable those patches to >> hit the list sooner than the patches for implementing devlink for the >> ice driver. > > Just to be clear - you mean implement triggering the dump over netlink? > FWIW that seems fairly reasonable to me, but please do explain the use > case clearly in the patches. > Yes. See the patches I just sent and let me know if the explanation isn't totally clear. > netdevsim is a driver mock up, and debugfs is its control interface. > The trigger there is to simulate an async device error, this trigger > should not be used as example or justification for anything real driver > may need. > The only two drivers that currently use regions at all are the mlx4 and the netdevsim driver. In order to have some example of how the new .trigger_snapshot and DEVLINK_CMD_REGION_TRIGGER work, (and so I could test them out easily) I chose to implement it in netdevsim. I'm working on patches for the ice driver that will implement devlink support, but that is still in progress and isn't really yet at a point where I can send it to the list. I wanted to get feedback on the implementation of the triggering earlier. Thanks, Jake ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-01-09 20:05 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-01-07 17:33 [question] About triggering a region snapshot through the devlink cmd Keller, Jacob E [not found] ` <HE1PR0502MB3771BD83B728249E6C21967AC33E0@HE1PR0502MB3771.eurprd05.prod.outlook.com> [not found] ` <HE1PR0502MB3771D512C2D23F551EB922F4C33E0@HE1PR0502MB3771.eurprd05.prod.outlook.com> 2020-01-08 19:14 ` FW: " Jacob Keller 2020-01-09 19:41 ` Jakub Kicinski 2020-01-09 20:05 ` Jacob Keller
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).