All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@amd.com>
To: Chengwen Feng <fengchengwen@huawei.com>, <thomas@monjalon.net>,
	<ferruh.yigit@xilinx.com>
Cc: <dev@dpdk.org>, <kalesh-anakkur.purayil@broadcom.com>,
	<somnath.kotur@broadcom.com>, <ajit.khaparde@broadcom.com>,
	<mdr@ashroe.eu>, <Andrew.Rybchenko@oktetlabs.ru>
Subject: Re: [PATCH v9 2/5] ethdev: support proactive error handling mode
Date: Mon, 3 Oct 2022 18:35:46 +0100	[thread overview]
Message-ID: <6db38a95-2412-8847-c9b3-379a3d83c037@amd.com> (raw)
In-Reply-To: <20220922074151.39450-3-fengchengwen@huawei.com>

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

<...>


  reply	other threads:[~2022-10-03 17:35 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20220128124831.427-1-kalesh-anakkur.purayil@broadcom.com>
2022-09-22  7:41 ` [PATCH v9 0/5] support error handling mode Chengwen Feng
2022-09-22  7:41   ` [PATCH v9 1/5] ethdev: support get port " Chengwen Feng
2022-10-03 17:35     ` Ferruh Yigit
2022-10-05  1:56       ` fengchengwen
2022-09-22  7:41   ` [PATCH v9 2/5] ethdev: support proactive " Chengwen Feng
2022-10-03 17:35     ` Ferruh Yigit [this message]
2022-09-22  7:41   ` [PATCH v9 3/5] app/testpmd: support error handling mode event Chengwen Feng
2022-09-22  7:41   ` [PATCH v9 4/5] net/hns3: support proactive error handling mode Chengwen Feng
2022-09-22  7:41   ` [PATCH v9 5/5] net/bnxt: " Chengwen Feng
2022-10-09  7:53 ` [PATCH v10 0/5] support " Chengwen Feng
2022-10-09  7:53   ` [PATCH v10 1/5] ethdev: support get port " Chengwen Feng
2022-10-09  7:53   ` [PATCH v10 2/5] ethdev: support proactive " Chengwen Feng
2022-10-09  7:53   ` [PATCH v10 3/5] app/testpmd: support error handling mode event Chengwen Feng
2022-10-09  7:53   ` [PATCH v10 4/5] net/hns3: support proactive error handling mode Chengwen Feng
2022-10-09  7:53   ` [PATCH v10 5/5] net/bnxt: " Chengwen Feng
2022-10-09  9:10 ` [PATCH v11 0/5] support " Chengwen Feng
2022-10-09  9:10   ` [PATCH v11 1/5] ethdev: support get port " Chengwen Feng
2022-10-10  8:38     ` Andrew Rybchenko
2022-10-10  8:44     ` Andrew Rybchenko
2022-10-09  9:10   ` [PATCH v11 2/5] ethdev: support proactive " Chengwen Feng
2022-10-10  8:47     ` Andrew Rybchenko
2022-10-11 14:48       ` fengchengwen
2022-10-09  9:10   ` [PATCH v11 3/5] app/testpmd: support error handling mode event Chengwen Feng
2022-10-09  9:10   ` [PATCH v11 4/5] net/hns3: support proactive error handling mode Chengwen Feng
2022-10-09 11:05     ` Dongdong Liu
2022-10-09  9:10   ` [PATCH v11 5/5] net/bnxt: " Chengwen Feng
2022-10-12  3:45 ` [PATCH v12 0/5] support " Chengwen Feng
2022-10-12  3:45   ` [PATCH v12 1/5] ethdev: add error handling mode to device info Chengwen Feng
2022-10-12  3:45   ` [PATCH v12 2/5] ethdev: support proactive error handling mode Chengwen Feng
2022-10-13  8:58     ` Andrew Rybchenko
2022-10-13 12:50       ` fengchengwen
2022-10-12  3:45   ` [PATCH v12 3/5] app/testpmd: support error handling mode event Chengwen Feng
2022-10-12  3:45   ` [PATCH v12 4/5] net/hns3: support proactive error handling mode Chengwen Feng
2022-10-12  3:45   ` [PATCH v12 5/5] net/bnxt: " Chengwen Feng
2022-10-13 12:42 ` [PATCH v13 0/5] support " Chengwen Feng
2022-10-13 12:42   ` [PATCH v13 1/5] ethdev: add error handling mode to device info Chengwen Feng
2022-10-13 12:42   ` [PATCH v13 2/5] ethdev: support proactive error handling mode Chengwen Feng
2022-10-13 12:42   ` [PATCH v13 3/5] app/testpmd: support error handling mode event Chengwen Feng
2022-10-13 12:42   ` [PATCH v13 4/5] net/hns3: support proactive error handling mode Chengwen Feng
2022-10-13 12:42   ` [PATCH v13 5/5] net/bnxt: " Chengwen Feng
2022-10-17  7:42   ` [PATCH v13 0/5] support " Andrew Rybchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6db38a95-2412-8847-c9b3-379a3d83c037@amd.com \
    --to=ferruh.yigit@amd.com \
    --cc=Andrew.Rybchenko@oktetlabs.ru \
    --cc=ajit.khaparde@broadcom.com \
    --cc=dev@dpdk.org \
    --cc=fengchengwen@huawei.com \
    --cc=ferruh.yigit@xilinx.com \
    --cc=kalesh-anakkur.purayil@broadcom.com \
    --cc=mdr@ashroe.eu \
    --cc=somnath.kotur@broadcom.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.