On 9/22/2022 8:41 AM, Chengwen Feng wrote:
From: Kalesh AP <kalesh-anakkur.pura...@broadcom.com>
Some PMDs (e.g. hns3) could detect hardware or firmware errors, and try
to recover from the errors. In this process, the PMD sets the data path
pointers to dummy functions (which will prevent the crash), and also
make sure the control path operations failed with retcode -EBUSY.
The above error handling mode is known as
RTE_ETH_ERROR_HANDLE_MODE_PROACTIVE (proactive error handling mode).
In some service scenarios, application needs to be aware of the event
to determine whether to migrate services. So three events were
introduced:
1) RTE_ETH_EVENT_ERR_RECOVERING: used to notify the application that it
detected an error and the recovery is being started. Upon receiving the
event, the application should not invoke any control path APIs until
receiving RTE_ETH_EVENT_RECOVERY_SUCCESS or
RTE_ETH_EVENT_RECOVERY_FAILED event.
2) RTE_ETH_EVENT_RECOVERY_SUCCESS: used to notify the application that
it recovers successful from the error, the PMD already re-configures
the port to the state prior to the error.
3) RTE_ETH_EVENT_RECOVERY_FAILED: used to notify the application that it
recovers failed from the error, the port should not usable anymore. The
application should close the port.
I think two separate events as 'RECOVERY_SUCCESS' & 'RECOVERY_FAILED' is
better than previous 'RECOVERED' event.
'RECOVERY_FAILED' is clear,
but for 'RECOVERY_SUCCESS' case, can we try to define more what
application should do?
Like should application assume nothing changed in the device
configuration, flow rules etc or on other extreme should it assume that
all configuration lost?
Signed-off-by: Kalesh AP <kalesh-anakkur.pura...@broadcom.com>
Signed-off-by: Somnath Kotur <somnath.ko...@broadcom.com>
Signed-off-by: Chengwen Feng <fengcheng...@huawei.com>
Reviewed-by: Ajit Khaparde <ajit.khapa...@broadcom.com>
<...>
