From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
To: Chengwen Feng <fengchengwen@huawei.com>,
thomas@monjalon.net, ferruh.yigit@xilinx.com,
ferruh.yigit@amd.com
Cc: dev@dpdk.org, kalesh-anakkur.purayil@broadcom.com,
somnath.kotur@broadcom.com, ajit.khaparde@broadcom.com,
mdr@ashroe.eu, Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: [PATCH v11 1/5] ethdev: support get port error handling mode
Date: Mon, 10 Oct 2022 11:38:27 +0300 [thread overview]
Message-ID: <ed4ca3ab-1379-3b54-eef2-946b30f1ce07@oktetlabs.ru> (raw)
In-Reply-To: <20221009091009.38978-2-fengchengwen@huawei.com>
On 10/9/22 12:10, Chengwen Feng wrote:
> This patch support gets port's error handling mode by
> rte_eth_dev_info_get() API.
Just: "Add error handling mode to device info."
>
> Currently, the defined modes include:
> 1) NONE: it means no error handling modes are supported by this port.
> 2) PASSIVE: passive error handling, after the PMD detect that a reset
> is required, the PMD reports RTE_ETH_EVENT_INTR_RESET event, and
> application invoke rte_eth_dev_reset() to recover the port.
>
> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
With review notes applied (may be except usage of reserved
fields):
Reviewed-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> index e8d1e1c658..3443bf20e1 100644
> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -1629,6 +1629,22 @@ enum rte_eth_representor_type {
> RTE_ETH_REPRESENTOR_PF, /**< representor of Physical Function. */
> };
>
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this enumeration may change without prior notice.
> + *
> + * Ethernet device error handling mode.
> + */
> +enum rte_eth_err_handle_mode {
> + /** No error handling modes are supported. */
> + RTE_ETH_ERROR_HANDLE_MODE_NONE,
> + /** Passive error handling, after the PMD detect that a reset is
> + * required, the PMD reports @see RTE_ETH_EVENT_INTR_RESET event, and
> + * application invoke @see rte_eth_dev_reset to recover the port.
> + */
> + RTE_ETH_ERROR_HANDLE_MODE_PASSIVE,
> +};
> +
> /**
> * A structure used to retrieve the contextual information of
> * an Ethernet device, such as the controlling driver of the
> @@ -1689,8 +1705,12 @@ struct rte_eth_dev_info {
> * embedded managed interconnect/switch.
> */
> struct rte_eth_switch_info switch_info;
> + /** Supported error handling mode. @see enum rte_eth_err_handle_mode */
> + uint8_t err_handle_mode;
IMHO, it must be
enum rte_eth_err_handle_mode err_handle_mode;
Yes, it takes a bit more space, but it is a control path and
code clearness is more important here than few extra bytes.
>
> - uint64_t reserved_64s[2]; /**< Reserved for future fields */
> + uint8_t reserved_8; /**< Reserved for future fields */
> + uint16_t reserved_16s[3]; /**< Reserved for future fields */
> + uint64_t reserved_64; /**< Reserved for future fields */
As far as I know it is done as per Stephen review notes, but
I'm not really sure why it is a right way in ABI breaking
release. I'd not touch it and just add a new field.
> void *reserved_ptrs[2]; /**< Reserved for future fields */
> };
>
next prev parent reply other threads:[~2022-10-10 8:38 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 " 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
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 [this message]
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=ed4ca3ab-1379-3b54-eef2-946b30f1ce07@oktetlabs.ru \
--to=andrew.rybchenko@oktetlabs.ru \
--cc=ajit.khaparde@broadcom.com \
--cc=dev@dpdk.org \
--cc=fengchengwen@huawei.com \
--cc=ferruh.yigit@amd.com \
--cc=ferruh.yigit@xilinx.com \
--cc=kalesh-anakkur.purayil@broadcom.com \
--cc=mdr@ashroe.eu \
--cc=somnath.kotur@broadcom.com \
--cc=stephen@networkplumber.org \
--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 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).