* RFC: Use of devlink/health report for non-Ethernet devices
@ 2020-02-03 23:01 Ray Jui
2020-02-04 6:48 ` Jiri Pirko
0 siblings, 1 reply; 3+ messages in thread
From: Ray Jui @ 2020-02-03 23:01 UTC (permalink / raw)
To: Jiri Pirko, David S. Miller, netdev
Cc: linux-kernel, Ray Jui, BCM Kernel Feedback
Hi Jiri/Eran/David,
I've been investigating the health report feature of devlink, and have a
couple related questions as follows:
1. Based on my investigation, it seems that devlink health report
mechanism provides the hook for a device driver to report errors, dump
debug information, trigger object dump, initiate self-recovery, and etc.
The current users of health report are all Ethernet based drivers.
However, it does not seem the health report framework prohibits the use
from any non-Ethernet based device drivers. Is my understanding correct?
2. Following my first question, in this case, do you think it makes any
sense to use devlink health report as a generic error reporting and
recovery mechanism, for other devices, e.g., NVMe and Virt I/O?
3. In the Ethernet device driver based use case, if one has a "smart
NIC" type of platform, i.e., running Linux on the embedded processor of
the NIC, it seems to make a lot of sense to also use devlink health
report to deal with other non-Ethernet specific errors, originated from
the embedded Linux (or any other OSes). The front-end driver that
registers various health reporters will still be an Ethernet based
device driver, running on the host server system. Does this make sense
to you?
Thanks in advance for your feedback!
Thanks,
Ray
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: RFC: Use of devlink/health report for non-Ethernet devices
2020-02-03 23:01 RFC: Use of devlink/health report for non-Ethernet devices Ray Jui
@ 2020-02-04 6:48 ` Jiri Pirko
2020-02-04 17:46 ` Ray Jui
0 siblings, 1 reply; 3+ messages in thread
From: Jiri Pirko @ 2020-02-04 6:48 UTC (permalink / raw)
To: Ray Jui
Cc: Jiri Pirko, David S. Miller, netdev, linux-kernel, BCM Kernel Feedback
Tue, Feb 04, 2020 at 12:01:37AM CET, ray.jui@broadcom.com wrote:
>Hi Jiri/Eran/David,
>
>I've been investigating the health report feature of devlink, and have a
>couple related questions as follows:
>
>1. Based on my investigation, it seems that devlink health report mechanism
>provides the hook for a device driver to report errors, dump debug
>information, trigger object dump, initiate self-recovery, and etc. The
>current users of health report are all Ethernet based drivers. However, it
>does not seem the health report framework prohibits the use from any
>non-Ethernet based device drivers. Is my understanding correct?
The whole devlink framework is designed to be independent on
ethernet/networking.
>
>2. Following my first question, in this case, do you think it makes any sense
>to use devlink health report as a generic error reporting and recovery
>mechanism, for other devices, e.g., NVMe and Virt I/O?
Sure.
>
>3. In the Ethernet device driver based use case, if one has a "smart NIC"
>type of platform, i.e., running Linux on the embedded processor of the NIC,
>it seems to make a lot of sense to also use devlink health report to deal
>with other non-Ethernet specific errors, originated from the embedded Linux
>(or any other OSes). The front-end driver that registers various health
>reporters will still be an Ethernet based device driver, running on the host
>server system. Does this make sense to you?
Should not be ethetnet based driver. You should create the devlink
instance in a driver for the particular device you want to report
the health for.
>
>Thanks in advance for your feedback!
>
>Thanks,
>
>Ray
>
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: RFC: Use of devlink/health report for non-Ethernet devices
2020-02-04 6:48 ` Jiri Pirko
@ 2020-02-04 17:46 ` Ray Jui
0 siblings, 0 replies; 3+ messages in thread
From: Ray Jui @ 2020-02-04 17:46 UTC (permalink / raw)
To: Jiri Pirko
Cc: Jiri Pirko, David S. Miller, netdev, linux-kernel, BCM Kernel Feedback
Hi Jiri,
On 2020-02-03 10:48 p.m., Jiri Pirko wrote:
> Tue, Feb 04, 2020 at 12:01:37AM CET, ray.jui@broadcom.com wrote:
>> Hi Jiri/Eran/David,
>>
>> I've been investigating the health report feature of devlink, and have a
>> couple related questions as follows:
>>
>> 1. Based on my investigation, it seems that devlink health report mechanism
>> provides the hook for a device driver to report errors, dump debug
>> information, trigger object dump, initiate self-recovery, and etc. The
>> current users of health report are all Ethernet based drivers. However, it
>> does not seem the health report framework prohibits the use from any
>> non-Ethernet based device drivers. Is my understanding correct?
>
> The whole devlink framework is designed to be independent on
> ethernet/networking.
>
>
Great. This is what I thought it is. Thanks for confirming.
>>
>> 2. Following my first question, in this case, do you think it makes any sense
>> to use devlink health report as a generic error reporting and recovery
>> mechanism, for other devices, e.g., NVMe and Virt I/O?
>
> Sure.
>
>
Thanks.
>>
>> 3. In the Ethernet device driver based use case, if one has a "smart NIC"
>> type of platform, i.e., running Linux on the embedded processor of the NIC,
>> it seems to make a lot of sense to also use devlink health report to deal
>> with other non-Ethernet specific errors, originated from the embedded Linux
>> (or any other OSes). The front-end driver that registers various health
>> reporters will still be an Ethernet based device driver, running on the host
>> server system. Does this make sense to you?
>
> Should not be ethetnet based driver. You should create the devlink
> instance in a driver for the particular device you want to report
> the health for.
>
>
Okay thanks!
>>
>> Thanks in advance for your feedback!
>>
>> Thanks,
>>
>> Ray
>>
>>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-02-04 17:46 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-03 23:01 RFC: Use of devlink/health report for non-Ethernet devices Ray Jui
2020-02-04 6:48 ` Jiri Pirko
2020-02-04 17:46 ` Ray Jui
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).