[PATCH v9 2/5] ethdev: support proactive error handling mode

[Ferruh Yigit]

On 9/22/2022 8:41 AM, Chengwen Feng wrote:
> From: Kalesh AP <kalesh-anakkur.purayil at 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.purayil at broadcom.com>
> Signed-off-by: Somnath Kotur <somnath.kotur at broadcom.com>
> Signed-off-by: Chengwen Feng <fengchengwen at huawei.com>
> Reviewed-by: Ajit Khaparde <ajit.khaparde at broadcom.com>

<...>