From: Haiyue Wang <haiyue.wang@intel.com>
To: dev@dpdk.org, qiming.yang@intel.com, qi.z.zhang@intel.com
Cc: junfeng.guo@intel.com, Haiyue Wang <haiyue.wang@intel.com>
Subject: [dpdk-dev] [PATCH v2] net/ice: optimize the FlexiMD hardware check
Date: Wed, 12 Aug 2020 08:57:53 +0800 [thread overview]
Message-ID: <20200812005753.467362-1-haiyue.wang@intel.com> (raw)
In-Reply-To: <20200811152044.462128-1-haiyue.wang@intel.com>
The Flexible Metadata #4 and #5 in the Rx Flex Descriptor are defined to
extract the protocol specified fields or its offset. Its function relays
on the DDP package support in hardware.
Optimize to only check the hardware support when the user specifies the
'proto_xtr' devargs. And not require all the types need to be support in
hardware, otherwise if new protocol extraction type is introduced, it is
hard to maintain the compatibility. Just check the type support in need.
And the protocol IDs are 8 bits length, so the uint8_t is the right type
to be used. Also introduce the 'opcode' variable to specify the metadata
extraction type: it can be protocol fields or offset report.
Signed-off-by: Haiyue Wang <haiyue.wang@intel.com>
---
v2: update the commit title and message.
---
drivers/net/ice/ice_ethdev.c | 66 ++++++++++++++++++++++--------------
drivers/net/ice/ice_ethdev.h | 1 +
2 files changed, 42 insertions(+), 25 deletions(-)
diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
index 8d435e889..d67390f29 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -47,6 +47,8 @@ struct proto_xtr_ol_flag {
bool required;
};
+static bool ice_proto_xtr_hw_support[PROTO_XTR_MAX];
+
static struct proto_xtr_ol_flag ice_proto_xtr_ol_flag_params[] = {
[PROTO_XTR_VLAN] = {
.param = { .name = "ice_dynflag_proto_xtr_vlan" },
@@ -536,25 +538,36 @@ handle_proto_xtr_arg(__rte_unused const char *key, const char *value,
return 0;
}
-static bool
-ice_proto_xtr_support(struct ice_hw *hw)
+static void
+ice_check_proto_xtr_support(struct ice_hw *hw)
{
#define FLX_REG(val, fld, idx) \
(((val) & GLFLXP_RXDID_FLX_WRD_##idx##_##fld##_M) >> \
GLFLXP_RXDID_FLX_WRD_##idx##_##fld##_S)
static struct {
uint32_t rxdid;
- uint16_t protid_0;
- uint16_t protid_1;
+ uint8_t opcode;
+ uint8_t protid_0;
+ uint8_t protid_1;
} xtr_sets[] = {
- { ICE_RXDID_COMMS_AUX_VLAN, ICE_PROT_EVLAN_O, ICE_PROT_VLAN_O },
- { ICE_RXDID_COMMS_AUX_IPV4, ICE_PROT_IPV4_OF_OR_S,
- ICE_PROT_IPV4_OF_OR_S },
- { ICE_RXDID_COMMS_AUX_IPV6, ICE_PROT_IPV6_OF_OR_S,
- ICE_PROT_IPV6_OF_OR_S },
- { ICE_RXDID_COMMS_AUX_IPV6_FLOW, ICE_PROT_IPV6_OF_OR_S,
- ICE_PROT_IPV6_OF_OR_S },
- { ICE_RXDID_COMMS_AUX_TCP, ICE_PROT_TCP_IL, ICE_PROT_ID_INVAL },
+ [PROTO_XTR_VLAN] = { ICE_RXDID_COMMS_AUX_VLAN,
+ ICE_RX_OPC_EXTRACT,
+ ICE_PROT_EVLAN_O, ICE_PROT_VLAN_O},
+ [PROTO_XTR_IPV4] = { ICE_RXDID_COMMS_AUX_IPV4,
+ ICE_RX_OPC_EXTRACT,
+ ICE_PROT_IPV4_OF_OR_S,
+ ICE_PROT_IPV4_OF_OR_S },
+ [PROTO_XTR_IPV6] = { ICE_RXDID_COMMS_AUX_IPV6,
+ ICE_RX_OPC_EXTRACT,
+ ICE_PROT_IPV6_OF_OR_S,
+ ICE_PROT_IPV6_OF_OR_S },
+ [PROTO_XTR_IPV6_FLOW] = { ICE_RXDID_COMMS_AUX_IPV6_FLOW,
+ ICE_RX_OPC_EXTRACT,
+ ICE_PROT_IPV6_OF_OR_S,
+ ICE_PROT_IPV6_OF_OR_S },
+ [PROTO_XTR_TCP] = { ICE_RXDID_COMMS_AUX_TCP,
+ ICE_RX_OPC_EXTRACT,
+ ICE_PROT_TCP_IL, ICE_PROT_ID_INVAL },
};
uint32_t i;
@@ -565,21 +578,19 @@ ice_proto_xtr_support(struct ice_hw *hw)
if (xtr_sets[i].protid_0 != ICE_PROT_ID_INVAL) {
v = ICE_READ_REG(hw, GLFLXP_RXDID_FLX_WRD_4(rxdid));
- if (FLX_REG(v, PROT_MDID, 4) != xtr_sets[i].protid_0 ||
- FLX_REG(v, RXDID_OPCODE, 4) != ICE_RX_OPC_EXTRACT)
- return false;
+ if (FLX_REG(v, PROT_MDID, 4) == xtr_sets[i].protid_0 &&
+ FLX_REG(v, RXDID_OPCODE, 4) == xtr_sets[i].opcode)
+ ice_proto_xtr_hw_support[i] = true;
}
if (xtr_sets[i].protid_1 != ICE_PROT_ID_INVAL) {
v = ICE_READ_REG(hw, GLFLXP_RXDID_FLX_WRD_5(rxdid));
- if (FLX_REG(v, PROT_MDID, 5) != xtr_sets[i].protid_1 ||
- FLX_REG(v, RXDID_OPCODE, 5) != ICE_RX_OPC_EXTRACT)
- return false;
+ if (FLX_REG(v, PROT_MDID, 5) == xtr_sets[i].protid_1 &&
+ FLX_REG(v, RXDID_OPCODE, 5) == xtr_sets[i].opcode)
+ ice_proto_xtr_hw_support[i] = true;
}
}
-
- return true;
}
static int
@@ -1416,11 +1427,6 @@ ice_init_proto_xtr(struct rte_eth_dev *dev)
int offset;
uint16_t i;
- if (!ice_proto_xtr_support(hw)) {
- PMD_DRV_LOG(NOTICE, "Protocol extraction is not supported");
- return;
- }
-
pf->proto_xtr = rte_zmalloc(NULL, pf->lan_nb_qps, 0);
if (unlikely(pf->proto_xtr == NULL)) {
PMD_DRV_LOG(ERR, "No memory for setting up protocol extraction table");
@@ -1443,6 +1449,8 @@ ice_init_proto_xtr(struct rte_eth_dev *dev)
if (likely(!proto_xtr_enable))
return;
+ ice_check_proto_xtr_support(hw);
+
offset = rte_mbuf_dynfield_register(&ice_proto_xtr_metadata_param);
if (unlikely(offset == -1)) {
PMD_DRV_LOG(ERR,
@@ -1462,6 +1470,14 @@ ice_init_proto_xtr(struct rte_eth_dev *dev)
if (!ol_flag->required)
continue;
+ if (!ice_proto_xtr_hw_support[i]) {
+ PMD_DRV_LOG(ERR,
+ "Protocol extraction type %u is not supported in hardware",
+ i);
+ rte_net_ice_dynfield_proto_xtr_metadata_offs = -1;
+ break;
+ }
+
offset = rte_mbuf_dynflag_register(&ol_flag->param);
if (unlikely(offset == -1)) {
PMD_DRV_LOG(ERR,
diff --git a/drivers/net/ice/ice_ethdev.h b/drivers/net/ice/ice_ethdev.h
index 393dfeab1..06b9b8683 100644
--- a/drivers/net/ice/ice_ethdev.h
+++ b/drivers/net/ice/ice_ethdev.h
@@ -262,6 +262,7 @@ enum proto_xtr_type {
PROTO_XTR_IPV6,
PROTO_XTR_IPV6_FLOW,
PROTO_XTR_TCP,
+ PROTO_XTR_MAX /* The last one */
};
enum ice_fdir_tunnel_type {
--
2.28.0
next prev parent reply other threads:[~2020-08-12 1:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-11 15:20 [dpdk-dev] [PATCH v1] net/ice: optimize the Rx metadata " Haiyue Wang
2020-08-12 0:57 ` Haiyue Wang [this message]
2020-08-31 3:53 ` [dpdk-dev] [PATCH v2] net/ice: optimize the FlexiMD " Zhang, Qi Z
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=20200812005753.467362-1-haiyue.wang@intel.com \
--to=haiyue.wang@intel.com \
--cc=dev@dpdk.org \
--cc=junfeng.guo@intel.com \
--cc=qi.z.zhang@intel.com \
--cc=qiming.yang@intel.com \
/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).