[dpdk-dev] [dpdk-dev 21.02 0/5] enable UDP ecpri configure in dcf

[dpdk-dev] [dpdk-dev 21.02 0/5] enable UDP ecpri configure in dcf

[Jeff Guo]

Enabling ecpri UDP tunnel port configure in dcf.

Jeff Guo (5):
  ethdev: add new tunnel type for ecpri
  net/ice/base: add new UDP tunnel type for ecpri
  net/ice: add ecpri package type
  net/ice: enable ecpri tunnel port configure in dcf
  app/testpmd: add new UDP tunnel port for ecpri

 app/test-pmd/cmdline.c               |   7 +-
 drivers/net/ice/base/ice_flex_pipe.c |   1 +
 drivers/net/ice/base/ice_flex_type.h |   1 +
 drivers/net/ice/ice_dcf_ethdev.c     |  67 +++++++++++++++
 drivers/net/ice/ice_ethdev.c         |   7 +-
 drivers/net/ice/ice_ethdev.h         |   1 +
 drivers/net/ice/ice_fdir_filter.c    |  66 ++++++++++++++
 drivers/net/ice/ice_hash.c           | 111 ++++++++++++++++++++++++
 drivers/net/ice/ice_rxtx.c           |  32 +++++++
 drivers/net/ice/ice_switch_filter.c  | 124 +++++++++++++++++++++++++++
 lib/librte_ethdev/rte_ethdev.h       |   1 +
 11 files changed, 415 insertions(+), 3 deletions(-)

-- 
2.20.1

[dpdk-dev] [dpdk-dev 21.02 1/5] ethdev: add new tunnel type for ecpri

[Jeff Guo]

Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunnel type.

Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
 lib/librte_ethdev/rte_ethdev.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index f5f8919186..2cbce958cf 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
 	RTE_TUNNEL_TYPE_IP_IN_GRE,
 	RTE_L2_TUNNEL_TYPE_E_TAG,
 	RTE_TUNNEL_TYPE_VXLAN_GPE,
+	RTE_TUNNEL_TYPE_ECPRI,
 	RTE_TUNNEL_TYPE_MAX,
 };
 
-- 
2.20.1

Re: [dpdk-dev] [dpdk-dev 21.02 1/5] ethdev: add new tunnel type for ecpri

[Zhang, Qi Z]

> -----Original Message-----
> From: Guo, Jia <jia.guo@intel.com>
> Sent: Wednesday, December 16, 2020 4:59 PM
> To: Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>;
> Yang, Qiming <qiming.yang@intel.com>; Wang, Haiyue
> <haiyue.wang@intel.com>
> Cc: dev@dpdk.org; Guo, Jia <jia.guo@intel.com>
> Subject: [dpdk-dev 21.02 1/5] ethdev: add new tunnel type for ecpri
> 
> Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunnel type.
> 
> Signed-off-by: Jeff Guo <jia.guo@intel.com>

Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>

Suggest to separate into 2 patcheset,
one for API/testpmd change (1, 5), one for PMD implementation (2-4) for easy review then merge.

> ---
>  lib/librte_ethdev/rte_ethdev.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> index f5f8919186..2cbce958cf 100644
> --- a/lib/librte_ethdev/rte_ethdev.h
> +++ b/lib/librte_ethdev/rte_ethdev.h
> @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
>  	RTE_TUNNEL_TYPE_IP_IN_GRE,
>  	RTE_L2_TUNNEL_TYPE_E_TAG,
>  	RTE_TUNNEL_TYPE_VXLAN_GPE,
> +	RTE_TUNNEL_TYPE_ECPRI,
>  	RTE_TUNNEL_TYPE_MAX,
>  };
> 
> --
> 2.20.1

[dpdk-dev] [dpdk-dev 21.02 2/5] net/ice/base: add new UDP tunnel type for ecpri

[Jeff Guo]

Add new UDP tunnel type for ecpri.

Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
 drivers/net/ice/base/ice_flex_pipe.c | 1 +
 drivers/net/ice/base/ice_flex_type.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/net/ice/base/ice_flex_pipe.c b/drivers/net/ice/base/ice_flex_pipe.c
index 7594df1696..fa8494e28d 100644
--- a/drivers/net/ice/base/ice_flex_pipe.c
+++ b/drivers/net/ice/base/ice_flex_pipe.c
@@ -13,6 +13,7 @@
 static const struct ice_tunnel_type_scan tnls[] = {
 	{ TNL_VXLAN,		"TNL_VXLAN_PF" },
 	{ TNL_GENEVE,		"TNL_GENEVE_PF" },
+	{ TNL_ECPRI,		"TNL_UDP_ECPRI_PF" },
 	{ TNL_LAST,		"" }
 };
 
diff --git a/drivers/net/ice/base/ice_flex_type.h b/drivers/net/ice/base/ice_flex_type.h
index 1dd57baccd..bf720753c1 100644
--- a/drivers/net/ice/base/ice_flex_type.h
+++ b/drivers/net/ice/base/ice_flex_type.h
@@ -516,6 +516,7 @@ struct ice_pkg_enum {
 enum ice_tunnel_type {
 	TNL_VXLAN = 0,
 	TNL_GENEVE,
+	TNL_ECPRI,
 	TNL_LAST = 0xFF,
 	TNL_ALL = 0xFF,
 };
-- 
2.20.1

[dpdk-dev] [dpdk-dev 21.02 3/5] net/ice: add ecpri package type

[Jeff Guo]

Add new ecpri package type and process the new package type when handle
each flow engines.

Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
 drivers/net/ice/ice_ethdev.c        |   7 +-
 drivers/net/ice/ice_ethdev.h        |   1 +
 drivers/net/ice/ice_fdir_filter.c   |  66 +++++++++++++++
 drivers/net/ice/ice_hash.c          | 111 +++++++++++++++++++++++++
 drivers/net/ice/ice_rxtx.c          |  32 +++++++
 drivers/net/ice/ice_switch_filter.c | 124 ++++++++++++++++++++++++++++
 6 files changed, 340 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
index 9a5d6a559f..ae1a22572f 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -71,7 +71,8 @@ static struct proto_xtr_ol_flag ice_proto_xtr_ol_flag_params[] = {
 #define ICE_DFLT_OUTER_TAG_TYPE ICE_AQ_VSI_OUTER_TAG_VLAN_9100
 
 #define ICE_OS_DEFAULT_PKG_NAME		"ICE OS Default Package"
-#define ICE_COMMS_PKG_NAME			"ICE COMMS Package"
+#define ICE_COMMS_PKG_NAME		"ICE COMMS Package"
+#define ICE_WIRELESS_EDGE_PKG_NAME	"ICE Wireless Edge Package"
 #define ICE_MAX_RES_DESC_NUM        1024
 
 static int ice_dev_configure(struct rte_eth_dev *dev);
@@ -1807,6 +1808,10 @@ ice_load_pkg_type(struct ice_hw *hw)
 	else if (!strncmp((char *)hw->active_pkg_name, ICE_COMMS_PKG_NAME,
 		ICE_PKG_NAME_SIZE))
 		package_type = ICE_PKG_TYPE_COMMS;
+	else if (!strncmp((char *)hw->active_pkg_name,
+			  ICE_WIRELESS_EDGE_PKG_NAME,
+			  ICE_PKG_NAME_SIZE))
+		package_type = ICE_PKG_TYPE_WIRELESS_EDGE;
 	else
 		package_type = ICE_PKG_TYPE_UNKNOWN;
 
diff --git a/drivers/net/ice/ice_ethdev.h b/drivers/net/ice/ice_ethdev.h
index 899f446cde..7f8d0e9087 100644
--- a/drivers/net/ice/ice_ethdev.h
+++ b/drivers/net/ice/ice_ethdev.h
@@ -147,6 +147,7 @@ enum ice_pkg_type {
 	ICE_PKG_TYPE_UNKNOWN,
 	ICE_PKG_TYPE_OS_DEFAULT,
 	ICE_PKG_TYPE_COMMS,
+	ICE_PKG_TYPE_WIRELESS_EDGE,
 };
 
 struct ice_adapter;
diff --git a/drivers/net/ice/ice_fdir_filter.c b/drivers/net/ice/ice_fdir_filter.c
index 175abcdd5c..5ca74bfb71 100644
--- a/drivers/net/ice/ice_fdir_filter.c
+++ b/drivers/net/ice/ice_fdir_filter.c
@@ -143,8 +143,62 @@ static struct ice_pattern_match_item ice_fdir_pattern_comms[] = {
 	{pattern_eth_ipv6_gtpu_eh,     ICE_FDIR_INSET_IPV6_GTPU_EH,          ICE_INSET_NONE},
 };
 
+static struct ice_pattern_match_item ice_fdir_pattern_wireless_edge[] = {
+	{pattern_ethertype,		ICE_FDIR_INSET_ETH,
+					ICE_INSET_NONE},
+	{pattern_eth_ipv4,		ICE_FDIR_INSET_ETH_IPV4,
+					ICE_INSET_NONE},
+	{pattern_eth_ipv4_udp,		ICE_FDIR_INSET_ETH_IPV4_UDP,
+					ICE_INSET_NONE},
+	{pattern_eth_ipv4_tcp,		ICE_FDIR_INSET_ETH_IPV4_TCP,
+					ICE_INSET_NONE},
+	{pattern_eth_ipv4_sctp,		ICE_FDIR_INSET_ETH_IPV4_SCTP,
+					ICE_INSET_NONE},
+	{pattern_eth_ipv6,		ICE_FDIR_INSET_ETH_IPV6,
+					ICE_INSET_NONE},
+	{pattern_eth_ipv6_udp,		ICE_FDIR_INSET_ETH_IPV6_UDP,
+					ICE_INSET_NONE},
+	{pattern_eth_ipv6_tcp,		ICE_FDIR_INSET_ETH_IPV6_TCP,
+					ICE_INSET_NONE},
+	{pattern_eth_ipv6_sctp,		ICE_FDIR_INSET_ETH_IPV6_SCTP,
+					ICE_INSET_NONE},
+	{pattern_eth_ipv4_udp_vxlan_ipv4,
+					ICE_FDIR_INSET_VXLAN_IPV4,
+					ICE_INSET_NONE},
+	{pattern_eth_ipv4_udp_vxlan_ipv4_udp,
+					ICE_FDIR_INSET_VXLAN_IPV4_UDP,
+					ICE_INSET_NONE},
+	{pattern_eth_ipv4_udp_vxlan_ipv4_tcp,
+					ICE_FDIR_INSET_VXLAN_IPV4_TCP,
+					ICE_INSET_NONE},
+	{pattern_eth_ipv4_udp_vxlan_ipv4_sctp,
+					ICE_FDIR_INSET_VXLAN_IPV4_SCTP,
+					ICE_INSET_NONE},
+	{pattern_eth_ipv4_udp_vxlan_eth_ipv4,
+					ICE_FDIR_INSET_VXLAN_IPV4,
+					ICE_INSET_NONE},
+	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_udp,
+					ICE_FDIR_INSET_VXLAN_IPV4_UDP,
+					ICE_INSET_NONE},
+	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_tcp,
+					ICE_FDIR_INSET_VXLAN_IPV4_TCP,
+					ICE_INSET_NONE},
+	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_sctp,
+					ICE_FDIR_INSET_VXLAN_IPV4_SCTP,
+					ICE_INSET_NONE},
+	{pattern_eth_ipv4_gtpu,		ICE_FDIR_INSET_IPV4_GTPU,
+					ICE_INSET_NONE},
+	{pattern_eth_ipv4_gtpu_eh,	ICE_FDIR_INSET_IPV4_GTPU_EH,
+					ICE_INSET_NONE},
+	{pattern_eth_ipv6_gtpu,		ICE_FDIR_INSET_IPV6_GTPU,
+					ICE_INSET_NONE},
+	{pattern_eth_ipv6_gtpu_eh,	ICE_FDIR_INSET_IPV6_GTPU_EH,
+					ICE_INSET_NONE},
+};
+
 static struct ice_flow_parser ice_fdir_parser_os;
 static struct ice_flow_parser ice_fdir_parser_comms;
+static struct ice_flow_parser ice_fdir_parser_wireless_edge;
 
 static int
 ice_fdir_is_tunnel_profile(enum ice_fdir_tunnel_type tunnel_type);
@@ -1113,6 +1167,8 @@ ice_fdir_init(struct ice_adapter *ad)
 
 	if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
 		parser = &ice_fdir_parser_comms;
+	else if (ad->active_pkg_type == ICE_PKG_TYPE_WIRELESS_EDGE)
+		parser = &ice_fdir_parser_wireless_edge;
 	else if (ad->active_pkg_type == ICE_PKG_TYPE_OS_DEFAULT)
 		parser = &ice_fdir_parser_os;
 	else
@@ -1132,6 +1188,8 @@ ice_fdir_uninit(struct ice_adapter *ad)
 
 	if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
 		parser = &ice_fdir_parser_comms;
+	else if (ad->active_pkg_type == ICE_PKG_TYPE_WIRELESS_EDGE)
+		parser = &ice_fdir_parser_wireless_edge;
 	else
 		parser = &ice_fdir_parser_os;
 
@@ -2083,6 +2141,14 @@ static struct ice_flow_parser ice_fdir_parser_comms = {
 	.stage = ICE_FLOW_STAGE_DISTRIBUTOR,
 };
 
+static struct ice_flow_parser ice_fdir_parser_wireless_edge = {
+	.engine = &ice_fdir_engine,
+	.array = ice_fdir_pattern_wireless_edge,
+	.array_len = RTE_DIM(ice_fdir_pattern_wireless_edge),
+	.parse_pattern_action = ice_fdir_parse,
+	.stage = ICE_FLOW_STAGE_DISTRIBUTOR,
+};
+
 RTE_INIT(ice_fdir_engine_register)
 {
 	ice_register_flow_engine(&ice_fdir_engine);
diff --git a/drivers/net/ice/ice_hash.c b/drivers/net/ice/ice_hash.c
index fe3e06c579..a52ede0173 100644
--- a/drivers/net/ice/ice_hash.c
+++ b/drivers/net/ice/ice_hash.c
@@ -446,6 +446,104 @@ static struct ice_pattern_match_item ice_hash_pattern_list_comms[] = {
 		&hint_eth_pppoes},
 };
 
+/* Supported pattern for wireless edge package. */
+static struct ice_pattern_match_item ice_hash_pattern_list_wireless_edge[] = {
+	{pattern_empty,			    ICE_INSET_NONE,
+		&hint_empty},
+	{pattern_eth_ipv4,		    ICE_INSET_NONE,
+		&hint_eth_ipv4},
+	{pattern_eth_ipv4_udp,		    ICE_INSET_NONE,
+		&hint_eth_ipv4_udp},
+	{pattern_eth_ipv4_tcp,		    ICE_INSET_NONE,
+		&hint_eth_ipv4_tcp},
+	{pattern_eth_ipv4_sctp,		    ICE_INSET_NONE,
+		&hint_eth_ipv4_sctp},
+	{pattern_eth_ipv4_gtpu_ipv4,	    ICE_INSET_NONE,
+		&hint_eth_ipv4_gtpu_ipv4},
+	{pattern_eth_ipv4_gtpu_ipv4_udp,    ICE_INSET_NONE,
+		&hint_eth_ipv4_gtpu_ipv4_udp},
+	{pattern_eth_ipv4_gtpu_ipv4_tcp,    ICE_INSET_NONE,
+		&hint_eth_ipv4_gtpu_ipv4_tcp},
+	{pattern_eth_ipv4_gtpu_ipv6,	    ICE_INSET_NONE,
+		&hint_eth_ipv4_gtpu_ipv6},
+	{pattern_eth_ipv4_gtpu_ipv6_udp,    ICE_INSET_NONE,
+		&hint_eth_ipv4_gtpu_ipv6_udp},
+	{pattern_eth_ipv4_gtpu_ipv6_tcp,    ICE_INSET_NONE,
+		&hint_eth_ipv4_gtpu_ipv6_tcp},
+	{pattern_eth_ipv6_gtpu_ipv4,	    ICE_INSET_NONE,
+		&hint_eth_ipv6_gtpu_ipv4},
+	{pattern_eth_ipv6_gtpu_ipv4_udp,    ICE_INSET_NONE,
+		&hint_eth_ipv6_gtpu_ipv4_udp},
+	{pattern_eth_ipv6_gtpu_ipv4_tcp,    ICE_INSET_NONE,
+		&hint_eth_ipv6_gtpu_ipv4_tcp},
+	{pattern_eth_ipv6_gtpu_ipv6,	    ICE_INSET_NONE,
+		&hint_eth_ipv6_gtpu_ipv6},
+	{pattern_eth_ipv6_gtpu_ipv6_udp,    ICE_INSET_NONE,
+		&hint_eth_ipv6_gtpu_ipv6_udp},
+	{pattern_eth_ipv6_gtpu_ipv6_tcp,    ICE_INSET_NONE,
+		&hint_eth_ipv6_gtpu_ipv6_tcp},
+	{pattern_eth_ipv4_gtpu_eh_ipv4,	    ICE_INSET_NONE,
+		&hint_eth_ipv4_gtpu_eh_ipv4},
+	{pattern_eth_ipv4_gtpu_eh_ipv4_udp, ICE_INSET_NONE,
+		&hint_eth_ipv4_gtpu_eh_ipv4_udp},
+	{pattern_eth_ipv4_gtpu_eh_ipv4_tcp, ICE_INSET_NONE,
+		&hint_eth_ipv4_gtpu_eh_ipv4_tcp},
+	{pattern_eth_ipv4_gtpu_eh_ipv6,	    ICE_INSET_NONE,
+		&hint_eth_ipv4_gtpu_eh_ipv6},
+	{pattern_eth_ipv4_gtpu_eh_ipv6_udp, ICE_INSET_NONE,
+		&hint_eth_ipv4_gtpu_eh_ipv6_udp},
+	{pattern_eth_ipv4_gtpu_eh_ipv6_tcp, ICE_INSET_NONE,
+		&hint_eth_ipv4_gtpu_eh_ipv6_tcp},
+	{pattern_eth_ipv6_gtpu_eh_ipv4,	    ICE_INSET_NONE,
+		&hint_eth_ipv6_gtpu_eh_ipv4},
+	{pattern_eth_ipv6_gtpu_eh_ipv4_udp, ICE_INSET_NONE,
+		&hint_eth_ipv6_gtpu_eh_ipv4_udp},
+	{pattern_eth_ipv6_gtpu_eh_ipv4_tcp, ICE_INSET_NONE,
+		&hint_eth_ipv6_gtpu_eh_ipv4_tcp},
+	{pattern_eth_ipv6_gtpu_eh_ipv6,	    ICE_INSET_NONE,
+		&hint_eth_ipv6_gtpu_eh_ipv6},
+	{pattern_eth_ipv6_gtpu_eh_ipv6_udp, ICE_INSET_NONE,
+		&hint_eth_ipv6_gtpu_eh_ipv6_udp},
+	{pattern_eth_ipv6_gtpu_eh_ipv6_tcp, ICE_INSET_NONE,
+		&hint_eth_ipv6_gtpu_eh_ipv6_tcp},
+	{pattern_eth_ipv4_esp,		    ICE_INSET_NONE,
+		&hint_eth_ipv4_esp},
+	{pattern_eth_ipv4_udp_esp,	    ICE_INSET_NONE,
+		&hint_eth_ipv4_udp_esp},
+	{pattern_eth_ipv4_ah,		    ICE_INSET_NONE,
+		&hint_eth_ipv4_ah},
+	{pattern_eth_vlan_ipv4,		    ICE_INSET_NONE,
+		&hint_eth_vlan_ipv4},
+	{pattern_eth_vlan_ipv4_udp,	    ICE_INSET_NONE,
+		&hint_eth_vlan_ipv4_udp},
+	{pattern_eth_vlan_ipv4_tcp,	    ICE_INSET_NONE,
+		&hint_eth_vlan_ipv4_tcp},
+	{pattern_eth_vlan_ipv4_sctp,	    ICE_INSET_NONE,
+		&hint_eth_vlan_ipv4_sctp},
+	{pattern_eth_ipv6,		    ICE_INSET_NONE,
+		&hint_eth_ipv6},
+	{pattern_eth_ipv6_udp,		    ICE_INSET_NONE,
+		&hint_eth_ipv6_udp},
+	{pattern_eth_ipv6_tcp,		    ICE_INSET_NONE,
+		&hint_eth_ipv6_tcp},
+	{pattern_eth_ipv6_sctp,		    ICE_INSET_NONE,
+		&hint_eth_ipv6_sctp},
+	{pattern_eth_ipv6_esp,		    ICE_INSET_NONE,
+		&hint_eth_ipv6_esp},
+	{pattern_eth_ipv6_udp_esp,	    ICE_INSET_NONE,
+		&hint_eth_ipv6_udp_esp},
+	{pattern_eth_ipv6_ah,		    ICE_INSET_NONE,
+		&hint_eth_ipv6_ah},
+	{pattern_eth_vlan_ipv6,		    ICE_INSET_NONE,
+		&hint_eth_vlan_ipv6},
+	{pattern_eth_vlan_ipv6_udp,	    ICE_INSET_NONE,
+		&hint_eth_vlan_ipv6_udp},
+	{pattern_eth_vlan_ipv6_tcp,	    ICE_INSET_NONE,
+		&hint_eth_vlan_ipv6_tcp},
+	{pattern_eth_vlan_ipv6_sctp,	    ICE_INSET_NONE,
+		&hint_eth_vlan_ipv6_sctp},
+};
+
 /**
  * The first member is input set combination,
  * the second member is hash fields.
@@ -932,6 +1030,15 @@ static struct ice_flow_parser ice_hash_parser_comms = {
 	.stage = ICE_FLOW_STAGE_RSS,
 };
 
+/* Register parser for wireless edge package. */
+static struct ice_flow_parser ice_hash_parser_wireless_edge = {
+	.engine = &ice_hash_engine,
+	.array = ice_hash_pattern_list_wireless_edge,
+	.array_len = RTE_DIM(ice_hash_pattern_list_wireless_edge),
+	.parse_pattern_action = ice_hash_parse_pattern_action,
+	.stage = ICE_FLOW_STAGE_RSS,
+};
+
 RTE_INIT(ice_hash_engine_init)
 {
 	struct ice_flow_engine *engine = &ice_hash_engine;
@@ -950,6 +1057,8 @@ ice_hash_init(struct ice_adapter *ad)
 		parser = &ice_hash_parser_os;
 	else if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
 		parser = &ice_hash_parser_comms;
+	else if (ad->active_pkg_type == ICE_PKG_TYPE_WIRELESS_EDGE)
+		parser = &ice_hash_parser_wireless_edge;
 	else
 		return -EINVAL;
 
@@ -1356,6 +1465,8 @@ ice_hash_uninit(struct ice_adapter *ad)
 		ice_unregister_parser(&ice_hash_parser_os, ad);
 	else if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
 		ice_unregister_parser(&ice_hash_parser_comms, ad);
+	else if (ad->active_pkg_type == ICE_PKG_TYPE_WIRELESS_EDGE)
+		ice_unregister_parser(&ice_hash_parser_wireless_edge, ad);
 }
 
 static void
diff --git a/drivers/net/ice/ice_rxtx.c b/drivers/net/ice/ice_rxtx.c
index d052bd0f1b..0cf7d6abb8 100644
--- a/drivers/net/ice/ice_rxtx.c
+++ b/drivers/net/ice/ice_rxtx.c
@@ -1948,8 +1948,40 @@ ice_dev_supported_ptypes_get(struct rte_eth_dev *dev)
 		RTE_PTYPE_UNKNOWN
 	};
 
+	static const uint32_t ptypes_wireless_edge[] = {
+		/* refers to ice_get_default_pkt_type() */
+		RTE_PTYPE_L2_ETHER,
+		RTE_PTYPE_L2_ETHER_TIMESYNC,
+		RTE_PTYPE_L2_ETHER_LLDP,
+		RTE_PTYPE_L2_ETHER_ARP,
+		RTE_PTYPE_L3_IPV4_EXT_UNKNOWN,
+		RTE_PTYPE_L3_IPV6_EXT_UNKNOWN,
+		RTE_PTYPE_L4_FRAG,
+		RTE_PTYPE_L4_ICMP,
+		RTE_PTYPE_L4_NONFRAG,
+		RTE_PTYPE_L4_SCTP,
+		RTE_PTYPE_L4_TCP,
+		RTE_PTYPE_L4_UDP,
+		RTE_PTYPE_TUNNEL_GRENAT,
+		RTE_PTYPE_TUNNEL_IP,
+		RTE_PTYPE_INNER_L2_ETHER,
+		RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN,
+		RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN,
+		RTE_PTYPE_INNER_L4_FRAG,
+		RTE_PTYPE_INNER_L4_ICMP,
+		RTE_PTYPE_INNER_L4_NONFRAG,
+		RTE_PTYPE_INNER_L4_SCTP,
+		RTE_PTYPE_INNER_L4_TCP,
+		RTE_PTYPE_INNER_L4_UDP,
+		RTE_PTYPE_TUNNEL_GTPC,
+		RTE_PTYPE_TUNNEL_GTPU,
+		RTE_PTYPE_UNKNOWN
+	};
+
 	if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
 		ptypes = ptypes_comms;
+	else if (ad->active_pkg_type == ICE_PKG_TYPE_WIRELESS_EDGE)
+		ptypes = ptypes_wireless_edge;
 	else
 		ptypes = ptypes_os;
 
diff --git a/drivers/net/ice/ice_switch_filter.c b/drivers/net/ice/ice_switch_filter.c
index 8cba6eb7b1..dc8578d5aa 100644
--- a/drivers/net/ice/ice_switch_filter.c
+++ b/drivers/net/ice/ice_switch_filter.c
@@ -139,8 +139,10 @@ struct sw_meta {
 
 static struct ice_flow_parser ice_switch_dist_parser_os;
 static struct ice_flow_parser ice_switch_dist_parser_comms;
+static struct ice_flow_parser ice_switch_dist_parser_wireless_edge;
 static struct ice_flow_parser ice_switch_perm_parser_os;
 static struct ice_flow_parser ice_switch_perm_parser_comms;
+static struct ice_flow_parser ice_switch_perm_parser_wireless_edge;
 
 static struct
 ice_pattern_match_item ice_switch_pattern_dist_os[] = {
@@ -264,6 +266,54 @@ ice_pattern_match_item ice_switch_pattern_dist_comms[] = {
 			ICE_INSET_NONE, ICE_INSET_NONE},
 };
 
+static struct
+ice_pattern_match_item ice_switch_pattern_dist_wireless_edge[] = {
+	{pattern_ethertype,
+			ICE_SW_INSET_ETHER, ICE_INSET_NONE},
+	{pattern_ethertype_vlan,
+			ICE_SW_INSET_MAC_VLAN, ICE_INSET_NONE},
+	{pattern_eth_arp,
+			ICE_INSET_NONE, ICE_INSET_NONE},
+	{pattern_eth_ipv4,
+			ICE_SW_INSET_MAC_IPV4, ICE_INSET_NONE},
+	{pattern_eth_ipv4_udp,
+			ICE_SW_INSET_MAC_IPV4_UDP, ICE_INSET_NONE},
+	{pattern_eth_ipv4_tcp,
+			ICE_SW_INSET_MAC_IPV4_TCP, ICE_INSET_NONE},
+	{pattern_eth_ipv6,
+			ICE_SW_INSET_MAC_IPV6, ICE_INSET_NONE},
+	{pattern_eth_ipv6_udp,
+			ICE_SW_INSET_MAC_IPV6_UDP, ICE_INSET_NONE},
+	{pattern_eth_ipv6_tcp,
+			ICE_SW_INSET_MAC_IPV6_TCP, ICE_INSET_NONE},
+	{pattern_eth_ipv4_udp_vxlan_eth_ipv4,
+			ICE_SW_INSET_DIST_VXLAN_IPV4, ICE_INSET_NONE},
+	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_udp,
+			ICE_SW_INSET_DIST_VXLAN_IPV4_UDP, ICE_INSET_NONE},
+	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_tcp,
+			ICE_SW_INSET_DIST_VXLAN_IPV4_TCP, ICE_INSET_NONE},
+	{pattern_eth_ipv4_nvgre_eth_ipv4,
+			ICE_SW_INSET_DIST_NVGRE_IPV4, ICE_INSET_NONE},
+	{pattern_eth_ipv4_nvgre_eth_ipv4_udp,
+			ICE_SW_INSET_DIST_NVGRE_IPV4_UDP, ICE_INSET_NONE},
+	{pattern_eth_ipv4_nvgre_eth_ipv4_tcp,
+			ICE_SW_INSET_DIST_NVGRE_IPV4_TCP, ICE_INSET_NONE},
+	{pattern_eth_ipv4_esp,
+			ICE_SW_INSET_MAC_IPV4_ESP, ICE_INSET_NONE},
+	{pattern_eth_ipv4_udp_esp,
+			ICE_SW_INSET_MAC_IPV4_ESP, ICE_INSET_NONE},
+	{pattern_eth_ipv6_esp,
+			ICE_SW_INSET_MAC_IPV6_ESP, ICE_INSET_NONE},
+	{pattern_eth_ipv6_udp_esp,
+			ICE_SW_INSET_MAC_IPV6_ESP, ICE_INSET_NONE},
+	{pattern_eth_ipv4_ah,
+			ICE_SW_INSET_MAC_IPV4_AH, ICE_INSET_NONE},
+	{pattern_eth_ipv6_ah,
+			ICE_SW_INSET_MAC_IPV6_AH, ICE_INSET_NONE},
+	{pattern_eth_ipv6_udp_ah,
+			ICE_INSET_NONE, ICE_INSET_NONE},
+};
+
 static struct
 ice_pattern_match_item ice_switch_pattern_perm_os[] = {
 	{pattern_ethertype,
@@ -386,6 +436,54 @@ ice_pattern_match_item ice_switch_pattern_perm_comms[] = {
 			ICE_INSET_NONE, ICE_INSET_NONE},
 };
 
+static struct
+ice_pattern_match_item ice_switch_pattern_perm_wireless_edge[] = {
+	{pattern_ethertype,
+			ICE_SW_INSET_ETHER, ICE_INSET_NONE},
+	{pattern_ethertype_vlan,
+			ICE_SW_INSET_MAC_VLAN, ICE_INSET_NONE},
+	{pattern_eth_arp,
+		ICE_INSET_NONE, ICE_INSET_NONE},
+	{pattern_eth_ipv4,
+			ICE_SW_INSET_MAC_IPV4, ICE_INSET_NONE},
+	{pattern_eth_ipv4_udp,
+			ICE_SW_INSET_MAC_IPV4_UDP, ICE_INSET_NONE},
+	{pattern_eth_ipv4_tcp,
+			ICE_SW_INSET_MAC_IPV4_TCP, ICE_INSET_NONE},
+	{pattern_eth_ipv6,
+			ICE_SW_INSET_MAC_IPV6, ICE_INSET_NONE},
+	{pattern_eth_ipv6_udp,
+			ICE_SW_INSET_MAC_IPV6_UDP, ICE_INSET_NONE},
+	{pattern_eth_ipv6_tcp,
+			ICE_SW_INSET_MAC_IPV6_TCP, ICE_INSET_NONE},
+	{pattern_eth_ipv4_udp_vxlan_eth_ipv4,
+			ICE_SW_INSET_PERM_TUNNEL_IPV4, ICE_INSET_NONE},
+	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_udp,
+			ICE_SW_INSET_PERM_TUNNEL_IPV4_UDP, ICE_INSET_NONE},
+	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_tcp,
+			ICE_SW_INSET_PERM_TUNNEL_IPV4_TCP, ICE_INSET_NONE},
+	{pattern_eth_ipv4_nvgre_eth_ipv4,
+			ICE_SW_INSET_PERM_TUNNEL_IPV4, ICE_INSET_NONE},
+	{pattern_eth_ipv4_nvgre_eth_ipv4_udp,
+			ICE_SW_INSET_PERM_TUNNEL_IPV4_UDP, ICE_INSET_NONE},
+	{pattern_eth_ipv4_nvgre_eth_ipv4_tcp,
+			ICE_SW_INSET_PERM_TUNNEL_IPV4_TCP, ICE_INSET_NONE},
+	{pattern_eth_ipv4_esp,
+			ICE_SW_INSET_MAC_IPV4_ESP, ICE_INSET_NONE},
+	{pattern_eth_ipv4_udp_esp,
+			ICE_SW_INSET_MAC_IPV4_ESP, ICE_INSET_NONE},
+	{pattern_eth_ipv6_esp,
+			ICE_SW_INSET_MAC_IPV6_ESP, ICE_INSET_NONE},
+	{pattern_eth_ipv6_udp_esp,
+			ICE_SW_INSET_MAC_IPV6_ESP, ICE_INSET_NONE},
+	{pattern_eth_ipv4_ah,
+			ICE_SW_INSET_MAC_IPV4_AH, ICE_INSET_NONE},
+	{pattern_eth_ipv6_ah,
+			ICE_SW_INSET_MAC_IPV6_AH, ICE_INSET_NONE},
+	{pattern_eth_ipv6_udp_ah,
+			ICE_INSET_NONE, ICE_INSET_NONE},
+};
+
 static int
 ice_switch_create(struct ice_adapter *ad,
 		struct rte_flow *flow,
@@ -1861,6 +1959,8 @@ ice_switch_init(struct ice_adapter *ad)
 
 	if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
 		dist_parser = &ice_switch_dist_parser_comms;
+	else if (ad->active_pkg_type == ICE_PKG_TYPE_WIRELESS_EDGE)
+		dist_parser = &ice_switch_dist_parser_wireless_edge;
 	else if (ad->active_pkg_type == ICE_PKG_TYPE_OS_DEFAULT)
 		dist_parser = &ice_switch_dist_parser_os;
 	else
@@ -1869,6 +1969,8 @@ ice_switch_init(struct ice_adapter *ad)
 	if (ad->devargs.pipe_mode_support) {
 		if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
 			perm_parser = &ice_switch_perm_parser_comms;
+		else if (ad->active_pkg_type == ICE_PKG_TYPE_WIRELESS_EDGE)
+			perm_parser = &ice_switch_perm_parser_wireless_edge;
 		else
 			perm_parser = &ice_switch_perm_parser_os;
 
@@ -1887,6 +1989,8 @@ ice_switch_uninit(struct ice_adapter *ad)
 
 	if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
 		dist_parser = &ice_switch_dist_parser_comms;
+	else if (ad->active_pkg_type == ICE_PKG_TYPE_WIRELESS_EDGE)
+		dist_parser = &ice_switch_dist_parser_wireless_edge;
 	else if (ad->active_pkg_type == ICE_PKG_TYPE_OS_DEFAULT)
 		dist_parser = &ice_switch_dist_parser_os;
 	else
@@ -1895,6 +1999,8 @@ ice_switch_uninit(struct ice_adapter *ad)
 	if (ad->devargs.pipe_mode_support) {
 		if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
 			perm_parser = &ice_switch_perm_parser_comms;
+		else if (ad->active_pkg_type == ICE_PKG_TYPE_WIRELESS_EDGE)
+			perm_parser = &ice_switch_perm_parser_wireless_edge;
 		else
 			perm_parser = &ice_switch_perm_parser_os;
 
@@ -1934,6 +2040,15 @@ ice_flow_parser ice_switch_dist_parser_comms = {
 	.stage = ICE_FLOW_STAGE_DISTRIBUTOR,
 };
 
+static struct
+ice_flow_parser ice_switch_dist_parser_wireless_edge = {
+	.engine = &ice_switch_engine,
+	.array = ice_switch_pattern_dist_wireless_edge,
+	.array_len = RTE_DIM(ice_switch_pattern_dist_wireless_edge),
+	.parse_pattern_action = ice_switch_parse_pattern_action,
+	.stage = ICE_FLOW_STAGE_DISTRIBUTOR,
+};
+
 static struct
 ice_flow_parser ice_switch_perm_parser_os = {
 	.engine = &ice_switch_engine,
@@ -1952,6 +2067,15 @@ ice_flow_parser ice_switch_perm_parser_comms = {
 	.stage = ICE_FLOW_STAGE_PERMISSION,
 };
 
+static struct
+ice_flow_parser ice_switch_perm_parser_wireless_edge = {
+	.engine = &ice_switch_engine,
+	.array = ice_switch_pattern_perm_wireless_edge,
+	.array_len = RTE_DIM(ice_switch_pattern_perm_wireless_edge),
+	.parse_pattern_action = ice_switch_parse_pattern_action,
+	.stage = ICE_FLOW_STAGE_PERMISSION,
+};
+
 RTE_INIT(ice_sw_engine_init)
 {
 	struct ice_flow_engine *engine = &ice_switch_engine;
-- 
2.20.1

[dpdk-dev] [dpdk-dev 21.02 4/5] net/ice: enable ecpri tunnel port configure in dcf

[Jeff Guo]

Add ecpri tunnel port add and rm ops to configure ecpri udp tunnel port
in dcf.

Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
 drivers/net/ice/ice_dcf_ethdev.c | 67 ++++++++++++++++++++++++++++++++
 1 file changed, 67 insertions(+)

diff --git a/drivers/net/ice/ice_dcf_ethdev.c b/drivers/net/ice/ice_dcf_ethdev.c
index b0b2ecb0d6..08265db79f 100644
--- a/drivers/net/ice/ice_dcf_ethdev.c
+++ b/drivers/net/ice/ice_dcf_ethdev.c
@@ -26,6 +26,13 @@
 #include "ice_dcf_ethdev.h"
 #include "ice_rxtx.h"
 
+static int
+ice_dcf_dev_udp_tunnel_port_add(struct rte_eth_dev *dev,
+				struct rte_eth_udp_tunnel *udp_tunnel);
+static int
+ice_dcf_dev_udp_tunnel_port_del(struct rte_eth_dev *dev,
+				struct rte_eth_udp_tunnel *udp_tunnel);
+
 static uint16_t
 ice_dcf_recv_pkts(__rte_unused void *rx_queue,
 		  __rte_unused struct rte_mbuf **bufs,
@@ -870,6 +877,64 @@ ice_dcf_link_update(__rte_unused struct rte_eth_dev *dev,
 	return 0;
 }
 
+/* Add UDP tunneling port */
+static int
+ice_dcf_dev_udp_tunnel_port_add(struct rte_eth_dev *dev,
+				struct rte_eth_udp_tunnel *udp_tunnel)
+{
+	struct ice_dcf_adapter *adapter = dev->data->dev_private;
+	struct ice_adapter *parent_adapter = &adapter->parent;
+	struct ice_hw *parent_hw = &parent_adapter->hw;
+	int ret = 0;
+
+	if (!udp_tunnel)
+		return -EINVAL;
+
+	switch (udp_tunnel->prot_type) {
+	case RTE_TUNNEL_TYPE_VXLAN:
+		ret = ice_create_tunnel(parent_hw, TNL_VXLAN,
+					udp_tunnel->udp_port);
+		break;
+	case RTE_TUNNEL_TYPE_ECPRI:
+		ret = ice_create_tunnel(parent_hw, TNL_ECPRI,
+					udp_tunnel->udp_port);
+		break;
+	default:
+		PMD_DRV_LOG(ERR, "Invalid tunnel type");
+		ret = -EINVAL;
+		break;
+	}
+
+	return ret;
+}
+
+/* Delete UDP tunneling port */
+static int
+ice_dcf_dev_udp_tunnel_port_del(struct rte_eth_dev *dev,
+				struct rte_eth_udp_tunnel *udp_tunnel)
+{
+	struct ice_dcf_adapter *adapter = dev->data->dev_private;
+	struct ice_adapter *parent_adapter = &adapter->parent;
+	struct ice_hw *parent_hw = &parent_adapter->hw;
+	int ret = 0;
+
+	if (!udp_tunnel)
+		return -EINVAL;
+
+	switch (udp_tunnel->prot_type) {
+	case RTE_TUNNEL_TYPE_VXLAN:
+	case RTE_TUNNEL_TYPE_ECPRI:
+		ret = ice_destroy_tunnel(parent_hw, udp_tunnel->udp_port, 0);
+		break;
+	default:
+		PMD_DRV_LOG(ERR, "Invalid tunnel type");
+		ret = -EINVAL;
+		break;
+	}
+
+	return ret;
+}
+
 static const struct eth_dev_ops ice_dcf_eth_dev_ops = {
 	.dev_start               = ice_dcf_dev_start,
 	.dev_stop                = ice_dcf_dev_stop,
@@ -892,6 +957,8 @@ static const struct eth_dev_ops ice_dcf_eth_dev_ops = {
 	.allmulticast_enable     = ice_dcf_dev_allmulticast_enable,
 	.allmulticast_disable    = ice_dcf_dev_allmulticast_disable,
 	.filter_ctrl             = ice_dcf_dev_filter_ctrl,
+	.udp_tunnel_port_add	 = ice_dcf_dev_udp_tunnel_port_add,
+	.udp_tunnel_port_del	 = ice_dcf_dev_udp_tunnel_port_del,
 };
 
 static int
-- 
2.20.1

[dpdk-dev] [dpdk-dev 21.02 5/5] app/testpmd: add new UDP tunnel port for ecpri

[Jeff Guo]

Add new UDP tunnel port params for ecpri configuration, the command
as below:

testpmd> port config 0 udp_tunnel_port add ecpri 6789
testpmd> port config 0 udp_tunnel_port rm ecpri 6789

Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
 app/test-pmd/cmdline.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 2ccbaa039e..af08e48e2e 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -9175,6 +9175,8 @@ cmd_cfg_tunnel_udp_port_parsed(void *parsed_result,
 		tunnel_udp.prot_type = RTE_TUNNEL_TYPE_GENEVE;
 	} else if (!strcmp(res->tunnel_type, "vxlan-gpe")) {
 		tunnel_udp.prot_type = RTE_TUNNEL_TYPE_VXLAN_GPE;
+	} else if (!strcmp(res->tunnel_type, "ecpri")) {
+		tunnel_udp.prot_type = RTE_TUNNEL_TYPE_ECPRI;
 	} else {
 		printf("Invalid tunnel type\n");
 		return;
@@ -9209,7 +9211,7 @@ cmdline_parse_token_string_t cmd_config_tunnel_udp_port_action =
 				 "add#rm");
 cmdline_parse_token_string_t cmd_config_tunnel_udp_port_tunnel_type =
 	TOKEN_STRING_INITIALIZER(struct cmd_config_tunnel_udp_port, tunnel_type,
-				 "vxlan#geneve#vxlan-gpe");
+				 "vxlan#geneve#vxlan-gpe#ecpri");
 cmdline_parse_token_num_t cmd_config_tunnel_udp_port_value =
 	TOKEN_NUM_INITIALIZER(struct cmd_config_tunnel_udp_port, udp_port,
 			      RTE_UINT16);
@@ -9217,7 +9219,8 @@ cmdline_parse_token_num_t cmd_config_tunnel_udp_port_value =
 cmdline_parse_inst_t cmd_cfg_tunnel_udp_port = {
 	.f = cmd_cfg_tunnel_udp_port_parsed,
 	.data = NULL,
-	.help_str = "port config <port_id> udp_tunnel_port add|rm vxlan|geneve|vxlan-gpe <udp_port>",
+	.help_str = "port config <port_id> udp_tunnel_port add|rm vxlan|"
+		"geneve|vxlan-gpe|ecpri <udp_port>",
 	.tokens = {
 		(void *)&cmd_config_tunnel_udp_port_port,
 		(void *)&cmd_config_tunnel_udp_port_config,
-- 
2.20.1

[dpdk-dev] [dpdk-dev v2 0/2] add new UDP tunnel port for ecpri

[Jeff Guo]

Add new UDP tunnel type and port params for ecpri configuration.

v2:
separate patch set

Jeff Guo (2):
  ethdev: add new tunnel type for ecpri
  app/testpmd: add new UDP tunnel port for ecpri

 app/test-pmd/cmdline.c         | 7 +++++--
 lib/librte_ethdev/rte_ethdev.h | 1 +
 2 files changed, 6 insertions(+), 2 deletions(-)

-- 
2.20.1

[dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Jeff Guo]

Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunnel type.

Signed-off-by: Jeff Guo <jia.guo@intel.com>
Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
---
 lib/librte_ethdev/rte_ethdev.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index f5f8919186..2cbce958cf 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
 	RTE_TUNNEL_TYPE_IP_IN_GRE,
 	RTE_L2_TUNNEL_TYPE_E_TAG,
 	RTE_TUNNEL_TYPE_VXLAN_GPE,
+	RTE_TUNNEL_TYPE_ECPRI,
 	RTE_TUNNEL_TYPE_MAX,
 };
 
-- 
2.20.1

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Thomas Monjalon]

24/12/2020 07:59, Jeff Guo:
> Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunnel type.
> 
> Signed-off-by: Jeff Guo <jia.guo@intel.com>
> Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
[...]
> --- a/lib/librte_ethdev/rte_ethdev.h
> +++ b/lib/librte_ethdev/rte_ethdev.h
> @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
>  	RTE_TUNNEL_TYPE_IP_IN_GRE,
>  	RTE_L2_TUNNEL_TYPE_E_TAG,
>  	RTE_TUNNEL_TYPE_VXLAN_GPE,
> +	RTE_TUNNEL_TYPE_ECPRI,
>  	RTE_TUNNEL_TYPE_MAX,
>  };

We tried to remove all these legacy API in DPDK 20.11.
Andrew decided to not remove this one because it is
not yet completely replaced by rte_flow in all drivers.
However, I am against continuing to update this API.
The opposite work should be done: migrate to rte_flow.

Sorry, it is a nack.
BTW, it is probably breaking the ABI because of RTE_TUNNEL_TYPE_MAX.

PS: please Cc ethdev maintainers for such patch, thanks.
tip: use --cc-cmd devtools/get-maintainer.sh

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Guo, Jia]

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Thursday, January 7, 2021 6:12 AM
> To: Guo, Jia <jia.guo@intel.com>
> Cc: Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing
> <jingjing.wu@intel.com>; Yang, Qiming <qiming.yang@intel.com>; Wang,
> Haiyue <haiyue.wang@intel.com>; dev@dpdk.org; Yigit, Ferruh
> <ferruh.yigit@intel.com>; andrew.rybchenko@oktetlabs.ru
> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for
> ecpri
> 
> 24/12/2020 07:59, Jeff Guo:
> > Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunnel
> type.
> >
> > Signed-off-by: Jeff Guo <jia.guo@intel.com>
> > Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
> [...]
> > --- a/lib/librte_ethdev/rte_ethdev.h
> > +++ b/lib/librte_ethdev/rte_ethdev.h
> > @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
> >  	RTE_TUNNEL_TYPE_IP_IN_GRE,
> >  	RTE_L2_TUNNEL_TYPE_E_TAG,
> >  	RTE_TUNNEL_TYPE_VXLAN_GPE,
> > +	RTE_TUNNEL_TYPE_ECPRI,
> >  	RTE_TUNNEL_TYPE_MAX,
> >  };
> 
> We tried to remove all these legacy API in DPDK 20.11.
> Andrew decided to not remove this one because it is not yet completely
> replaced by rte_flow in all drivers.
> However, I am against continuing to update this API.
> The opposite work should be done: migrate to rte_flow.
> 

Agree but seems that the legacy api and driver legacy implementation still keep in this release, and there is no a general way to replace the legacy by rte_flow right now.

> Sorry, it is a nack.
> BTW, it is probably breaking the ABI because of RTE_TUNNEL_TYPE_MAX.
> 

Oh, the ABI break should be a problem.

> PS: please Cc ethdev maintainers for such patch, thanks.
> tip: use --cc-cmd devtools/get-maintainer.sh
> 

Thanks for your helpful tip.

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Andrew Rybchenko]

On 1/7/21 12:32 PM, Guo, Jia wrote:
> 
>> -----Original Message-----
>> From: Thomas Monjalon <thomas@monjalon.net>
>> Sent: Thursday, January 7, 2021 6:12 AM
>> To: Guo, Jia <jia.guo@intel.com>
>> Cc: Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing
>> <jingjing.wu@intel.com>; Yang, Qiming <qiming.yang@intel.com>; Wang,
>> Haiyue <haiyue.wang@intel.com>; dev@dpdk.org; Yigit, Ferruh
>> <ferruh.yigit@intel.com>; andrew.rybchenko@oktetlabs.ru
>> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for
>> ecpri
>>
>> 24/12/2020 07:59, Jeff Guo:
>>> Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunnel
>> type.
>>>
>>> Signed-off-by: Jeff Guo <jia.guo@intel.com>
>>> Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
>> [...]
>>> --- a/lib/librte_ethdev/rte_ethdev.h
>>> +++ b/lib/librte_ethdev/rte_ethdev.h
>>> @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
>>>   	RTE_TUNNEL_TYPE_IP_IN_GRE,
>>>   	RTE_L2_TUNNEL_TYPE_E_TAG,
>>>   	RTE_TUNNEL_TYPE_VXLAN_GPE,
>>> +	RTE_TUNNEL_TYPE_ECPRI,
>>>   	RTE_TUNNEL_TYPE_MAX,
>>>   };
>>
>> We tried to remove all these legacy API in DPDK 20.11.
>> Andrew decided to not remove this one because it is not yet completely
>> replaced by rte_flow in all drivers.
>> However, I am against continuing to update this API.
>> The opposite work should be done: migrate to rte_flow.
>>
> 
> Agree but seems that the legacy api and driver legacy implementation still keep in this release, and there is no a general way to replace the legacy by rte_flow right now.

Which legacy API is kept? (I've tried to cleanup drivers, but it is not
always easy to do and I relied on driver maintainers)

If you are talking about an API to set UDP port for UDP-based tunnels,
yes it is kept right now since there is no replacement yet.

It looks like eCRPI could be encapsulated in UDP, but I don't know
if UDP port is fixed for the tunnel type or requires configuring.

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Thomas Monjalon]

07/01/2021 10:32, Guo, Jia:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 24/12/2020 07:59, Jeff Guo:
> > > Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunnel
> > type.
> > >
> > > Signed-off-by: Jeff Guo <jia.guo@intel.com>
> > > Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
> > [...]
> > > --- a/lib/librte_ethdev/rte_ethdev.h
> > > +++ b/lib/librte_ethdev/rte_ethdev.h
> > > @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
> > >  	RTE_TUNNEL_TYPE_IP_IN_GRE,
> > >  	RTE_L2_TUNNEL_TYPE_E_TAG,
> > >  	RTE_TUNNEL_TYPE_VXLAN_GPE,
> > > +	RTE_TUNNEL_TYPE_ECPRI,
> > >  	RTE_TUNNEL_TYPE_MAX,
> > >  };
> > 
> > We tried to remove all these legacy API in DPDK 20.11.
> > Andrew decided to not remove this one because it is not yet completely
> > replaced by rte_flow in all drivers.
> > However, I am against continuing to update this API.
> > The opposite work should be done: migrate to rte_flow.
> 
> Agree but seems that the legacy api and driver legacy implementation
> still keep in this release, and there is no a general way to replace
> the legacy by rte_flow right now.

I think rte_flow is a complete replacement with more features.
You can match, encap, decap.
There is even a new API to get tunnel infos after decap.
What is missing?


> > Sorry, it is a nack.
> > BTW, it is probably breaking the ABI because of RTE_TUNNEL_TYPE_MAX.
> 
> Oh, the ABI break should be a problem.
> 
> > PS: please Cc ethdev maintainers for such patch, thanks.
> > tip: use --cc-cmd devtools/get-maintainer.sh
> 
> Thanks for your helpful tip.

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Zhang, Qi Z]

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Thursday, January 7, 2021 6:12 PM
> To: Guo, Jia <jia.guo@intel.com>
> Cc: Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>;
> Yang, Qiming <qiming.yang@intel.com>; Wang, Haiyue
> <haiyue.wang@intel.com>; dev@dpdk.org; Yigit, Ferruh
> <ferruh.yigit@intel.com>; andrew.rybchenko@oktetlabs.ru; orika@nvidia.com;
> getelson@nvidia.com
> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
> 
> 07/01/2021 10:32, Guo, Jia:
> > From: Thomas Monjalon <thomas@monjalon.net>
> > > 24/12/2020 07:59, Jeff Guo:
> > > > Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunnel
> > > type.
> > > >
> > > > Signed-off-by: Jeff Guo <jia.guo@intel.com>
> > > > Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
> > > [...]
> > > > --- a/lib/librte_ethdev/rte_ethdev.h
> > > > +++ b/lib/librte_ethdev/rte_ethdev.h
> > > > @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
> > > >  	RTE_TUNNEL_TYPE_IP_IN_GRE,
> > > >  	RTE_L2_TUNNEL_TYPE_E_TAG,
> > > >  	RTE_TUNNEL_TYPE_VXLAN_GPE,
> > > > +	RTE_TUNNEL_TYPE_ECPRI,
> > > >  	RTE_TUNNEL_TYPE_MAX,
> > > >  };
> > >
> > > We tried to remove all these legacy API in DPDK 20.11.
> > > Andrew decided to not remove this one because it is not yet
> > > completely replaced by rte_flow in all drivers.
> > > However, I am against continuing to update this API.
> > > The opposite work should be done: migrate to rte_flow.
> >
> > Agree but seems that the legacy api and driver legacy implementation
> > still keep in this release, and there is no a general way to replace
> > the legacy by rte_flow right now.
> 
> I think rte_flow is a complete replacement with more features.

Thomas, I may not agree with this.

Actually the "enum rte_eth_tunnel_type" is used by rte_eth_dev_udp_tunnel_port_add 
A packet with specific dst udp port will be recognized as a specific tunnel packet type (e.g. vxlan, vxlan-gpe, ecpri...)
In Intel NIC, the API actually changes the configuration of the packet parser in HW but not add a filter rule and I guess all other devices may enable it in a similar way.
so naturally it should be a device (port) level configuration but not a rte_flow rule for match, encap, decap...
So I think it's not a good idea to replace the rte_eth_dev_udp_tunnel_port_add with rte_flow config
and also there is no existing rte_flow_action can cover this requirement unless we introduce some new one.

> You can match, encap, decap.
> There is even a new API to get tunnel infos after decap.
> What is missing?
> 
> 
> > > Sorry, it is a nack.
> > > BTW, it is probably breaking the ABI because of RTE_TUNNEL_TYPE_MAX.

Yes that may break the ABI but fortunately the checking-abi-compatibility tool shows negative :) , thanks Ferruh' s guide.
https://github.com/ferruhy/dpdk/actions/runs/468859673

Thanks
Qi

> >
> > Oh, the ABI break should be a problem.
> >
> > > PS: please Cc ethdev maintainers for such patch, thanks.
> > > tip: use --cc-cmd devtools/get-maintainer.sh
> >
> > Thanks for your helpful tip.
> 
> 

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Thomas Monjalon]

07/01/2021 13:47, Zhang, Qi Z:
> 
> > -----Original Message-----
> > From: Thomas Monjalon <thomas@monjalon.net>
> > Sent: Thursday, January 7, 2021 6:12 PM
> > To: Guo, Jia <jia.guo@intel.com>
> > Cc: Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>;
> > Yang, Qiming <qiming.yang@intel.com>; Wang, Haiyue
> > <haiyue.wang@intel.com>; dev@dpdk.org; Yigit, Ferruh
> > <ferruh.yigit@intel.com>; andrew.rybchenko@oktetlabs.ru; orika@nvidia.com;
> > getelson@nvidia.com
> > Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
> > 
> > 07/01/2021 10:32, Guo, Jia:
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > 24/12/2020 07:59, Jeff Guo:
> > > > > Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunnel
> > > > type.
> > > > >
> > > > > Signed-off-by: Jeff Guo <jia.guo@intel.com>
> > > > > Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
> > > > [...]
> > > > > --- a/lib/librte_ethdev/rte_ethdev.h
> > > > > +++ b/lib/librte_ethdev/rte_ethdev.h
> > > > > @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
> > > > >  	RTE_TUNNEL_TYPE_IP_IN_GRE,
> > > > >  	RTE_L2_TUNNEL_TYPE_E_TAG,
> > > > >  	RTE_TUNNEL_TYPE_VXLAN_GPE,
> > > > > +	RTE_TUNNEL_TYPE_ECPRI,
> > > > >  	RTE_TUNNEL_TYPE_MAX,
> > > > >  };
> > > >
> > > > We tried to remove all these legacy API in DPDK 20.11.
> > > > Andrew decided to not remove this one because it is not yet
> > > > completely replaced by rte_flow in all drivers.
> > > > However, I am against continuing to update this API.
> > > > The opposite work should be done: migrate to rte_flow.
> > >
> > > Agree but seems that the legacy api and driver legacy implementation
> > > still keep in this release, and there is no a general way to replace
> > > the legacy by rte_flow right now.
> > 
> > I think rte_flow is a complete replacement with more features.
> 
> Thomas, I may not agree with this.
> 
> Actually the "enum rte_eth_tunnel_type" is used by rte_eth_dev_udp_tunnel_port_add 
> A packet with specific dst udp port will be recognized as a specific tunnel packet type (e.g. vxlan, vxlan-gpe, ecpri...)
> In Intel NIC, the API actually changes the configuration of the packet parser in HW but not add a filter rule and I guess all other devices may enable it in a similar way.
> so naturally it should be a device (port) level configuration but not a rte_flow rule for match, encap, decap...

I don't understand how it helps to identify an UDP port
if there is no rule for this tunnel.
What is the usage?

> So I think it's not a good idea to replace
> the rte_eth_dev_udp_tunnel_port_add with rte_flow config
> and also there is no existing rte_flow_action
> can cover this requirement unless we introduce some new one.
> 
> > You can match, encap, decap.
> > There is even a new API to get tunnel infos after decap.
> > What is missing?

I still don't see which use case is missing.


> > > > Sorry, it is a nack.
> > > > BTW, it is probably breaking the ABI because of RTE_TUNNEL_TYPE_MAX.
> 
> Yes that may break the ABI but fortunately the checking-abi-compatibility tool shows negative :) , thanks Ferruh' s guide.
> https://github.com/ferruhy/dpdk/actions/runs/468859673

That's very strange. An enum value is changed.
Why it is not flagged by libabigail?


> > > Oh, the ABI break should be a problem.
> > >
> > > > PS: please Cc ethdev maintainers for such patch, thanks.
> > > > tip: use --cc-cmd devtools/get-maintainer.sh
> > >
> > > Thanks for your helpful tip.

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[David Marchand]

On Thu, Jan 7, 2021 at 2:33 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > Yes that may break the ABI but fortunately the checking-abi-compatibility tool shows negative :) , thanks Ferruh' s guide.
> > https://github.com/ferruhy/dpdk/actions/runs/468859673
>
> That's very strange. An enum value is changed.
> Why it is not flagged by libabigail?

I suspect this is because the enum is not referenced in any object...
all I see is an integer with a comment that it should be filled with
values from the enum.

-- 
David Marchand

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Dodji Seketeli]

David Marchand <david.marchand@redhat.com> writes:

> On Thu, Jan 7, 2021 at 2:33 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>> > Yes that may break the ABI but fortunately the checking-abi-compatibility tool shows negative :) , thanks Ferruh' s guide.
>> > https://github.com/ferruhy/dpdk/actions/runs/468859673
>>
>> That's very strange. An enum value is changed.
>> Why it is not flagged by libabigail?
>
> I suspect this is because the enum is not referenced in any object...
> all I see is an integer with a comment that it should be filled with
> values from the enum.

I am not sure about the full context but David is right in theory.

If the enum is not reachable from a publically exported interface
(function or global variable) then it won't we considered as being part
of the ABI and changes to that enum won't be reported.

I am not sure if that is what is happening in this particular case,
though.

Cheers,

-- 
		Dodji

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Zhang, Qi Z]

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Thursday, January 7, 2021 9:34 PM
> To: Guo, Jia <jia.guo@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
> <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
> dev@dpdk.org; Yigit, Ferruh <ferruh.yigit@intel.com>;
> andrew.rybchenko@oktetlabs.ru; orika@nvidia.com; getelson@nvidia.com;
> Dodji Seketeli <dodji@redhat.com>
> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
> 
> 07/01/2021 13:47, Zhang, Qi Z:
> >
> > > -----Original Message-----
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > > Sent: Thursday, January 7, 2021 6:12 PM
> > > To: Guo, Jia <jia.guo@intel.com>
> > > Cc: Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing
> > > <jingjing.wu@intel.com>; Yang, Qiming <qiming.yang@intel.com>; Wang,
> > > Haiyue <haiyue.wang@intel.com>; dev@dpdk.org; Yigit, Ferruh
> > > <ferruh.yigit@intel.com>; andrew.rybchenko@oktetlabs.ru;
> > > orika@nvidia.com; getelson@nvidia.com
> > > Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel
> > > type for ecpri
> > >
> > > 07/01/2021 10:32, Guo, Jia:
> > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > 24/12/2020 07:59, Jeff Guo:
> > > > > > Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev
> > > > > > tunnel
> > > > > type.
> > > > > >
> > > > > > Signed-off-by: Jeff Guo <jia.guo@intel.com>
> > > > > > Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
> > > > > [...]
> > > > > > --- a/lib/librte_ethdev/rte_ethdev.h
> > > > > > +++ b/lib/librte_ethdev/rte_ethdev.h
> > > > > > @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
> > > > > >  	RTE_TUNNEL_TYPE_IP_IN_GRE,
> > > > > >  	RTE_L2_TUNNEL_TYPE_E_TAG,
> > > > > >  	RTE_TUNNEL_TYPE_VXLAN_GPE,
> > > > > > +	RTE_TUNNEL_TYPE_ECPRI,
> > > > > >  	RTE_TUNNEL_TYPE_MAX,
> > > > > >  };
> > > > >
> > > > > We tried to remove all these legacy API in DPDK 20.11.
> > > > > Andrew decided to not remove this one because it is not yet
> > > > > completely replaced by rte_flow in all drivers.
> > > > > However, I am against continuing to update this API.
> > > > > The opposite work should be done: migrate to rte_flow.
> > > >
> > > > Agree but seems that the legacy api and driver legacy
> > > > implementation still keep in this release, and there is no a
> > > > general way to replace the legacy by rte_flow right now.
> > >
> > > I think rte_flow is a complete replacement with more features.
> >
> > Thomas, I may not agree with this.
> >
> > Actually the "enum rte_eth_tunnel_type" is used by
> > rte_eth_dev_udp_tunnel_port_add A packet with specific dst udp port
> > will be recognized as a specific tunnel packet type (e.g. vxlan, vxlan-gpe,
> ecpri...) In Intel NIC, the API actually changes the configuration of the packet
> parser in HW but not add a filter rule and I guess all other devices may enable it
> in a similar way.
> > so naturally it should be a device (port) level configuration but not a rte_flow
> rule for match, encap, decap...
> 
> I don't understand how it helps to identify an UDP port if there is no rule for
> this tunnel.
> What is the usage?

Yes, in general It is a rule, it matches a udp packet's dst port and the action is "now the packet is identified as vxlan packet" then all other rte_flow rules that match for a vlxan as pattern will take effect.  but somehow, I think they are not rules in the same domain, just like we have dedicate API for mac/vlan filter, we'd better have a dedicate API for this also. ( RFC for Vxlan explains why we need this. https://tools.ietf.org/html/rfc7348).

"Destination Port: IANA has assigned the value 4789 for the
VXLAN UDP port, and this value SHOULD be used by default as the
destination UDP port.  Some early implementations of VXLAN have
used other values for the destination port.  To enable
interoperability with these implementations, the destination
port SHOULD be configurable."

Thanks
Qi

> 
> > So I think it's not a good idea to replace the
> > rte_eth_dev_udp_tunnel_port_add with rte_flow config and also there is
> > no existing rte_flow_action can cover this requirement unless we
> > introduce some new one.
> >
> > > You can match, encap, decap.
> > > There is even a new API to get tunnel infos after decap.
> > > What is missing?
> 
> I still don't see which use case is missing.
> 
> 
> > > > > Sorry, it is a nack.
> > > > > BTW, it is probably breaking the ABI because of
> RTE_TUNNEL_TYPE_MAX.
> >
> > Yes that may break the ABI but fortunately the checking-abi-compatibility tool
> shows negative :) , thanks Ferruh' s guide.
> > https://github.com/ferruhy/dpdk/actions/runs/468859673
> 
> That's very strange. An enum value is changed.
> Why it is not flagged by libabigail?
> 
> 
> > > > Oh, the ABI break should be a problem.
> > > >
> > > > > PS: please Cc ethdev maintainers for such patch, thanks.
> > > > > tip: use --cc-cmd devtools/get-maintainer.sh
> > > >
> > > > Thanks for your helpful tip.
> 
> 

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Thomas Monjalon]

07/01/2021 16:24, Zhang, Qi Z:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 07/01/2021 13:47, Zhang, Qi Z:
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > 07/01/2021 10:32, Guo, Jia:
> > > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > 24/12/2020 07:59, Jeff Guo:
> > > > > > > --- a/lib/librte_ethdev/rte_ethdev.h
> > > > > > > +++ b/lib/librte_ethdev/rte_ethdev.h
> > > > > > > @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
> > > > > > >  	RTE_TUNNEL_TYPE_IP_IN_GRE,
> > > > > > >  	RTE_L2_TUNNEL_TYPE_E_TAG,
> > > > > > >  	RTE_TUNNEL_TYPE_VXLAN_GPE,
> > > > > > > +	RTE_TUNNEL_TYPE_ECPRI,
> > > > > > >  	RTE_TUNNEL_TYPE_MAX,
> > > > > > >  };
> > > > > >
> > > > > > We tried to remove all these legacy API in DPDK 20.11.
> > > > > > Andrew decided to not remove this one because it is not yet
> > > > > > completely replaced by rte_flow in all drivers.
> > > > > > However, I am against continuing to update this API.
> > > > > > The opposite work should be done: migrate to rte_flow.
> > > > >
> > > > > Agree but seems that the legacy api and driver legacy
> > > > > implementation still keep in this release, and there is no a
> > > > > general way to replace the legacy by rte_flow right now.
> > > >
> > > > I think rte_flow is a complete replacement with more features.
> > >
> > > Thomas, I may not agree with this.
> > >
> > > Actually the "enum rte_eth_tunnel_type" is used by
> > > rte_eth_dev_udp_tunnel_port_add A packet with specific dst udp port
> > > will be recognized as a specific tunnel packet type (e.g. vxlan, vxlan-gpe,
> > ecpri...) In Intel NIC, the API actually changes the configuration of the packet
> > parser in HW but not add a filter rule and I guess all other devices may enable it
> > in a similar way.
> > > so naturally it should be a device (port) level configuration but not a rte_flow
> > rule for match, encap, decap...
> > 
> > I don't understand how it helps to identify an UDP port if there is no rule for
> > this tunnel.
> > What is the usage?
> 
> Yes, in general It is a rule, it matches a udp packet's dst port and the action is "now the packet is identified as vxlan packet" then all other rte_flow rules that match for a vlxan as pattern will take effect.  but somehow, I think they are not rules in the same domain, just like we have dedicate API for mac/vlan filter, we'd better have a dedicate API for this also. ( RFC for Vxlan explains why we need this. https://tools.ietf.org/html/rfc7348).
> 
> "Destination Port: IANA has assigned the value 4789 for the
> VXLAN UDP port, and this value SHOULD be used by default as the
> destination UDP port.  Some early implementations of VXLAN have
> used other values for the destination port.  To enable
> interoperability with these implementations, the destination
> port SHOULD be configurable."

Yes the port number is free.
But isn't it more natural to specify this port number
as part of the rte_flow rule?

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Zhang, Qi Z]

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Friday, January 8, 2021 12:59 AM
> To: Guo, Jia <jia.guo@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
> <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
> dev@dpdk.org; Yigit, Ferruh <ferruh.yigit@intel.com>;
> andrew.rybchenko@oktetlabs.ru; orika@nvidia.com; getelson@nvidia.com;
> Dodji Seketeli <dodji@redhat.com>
> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
> 
> 07/01/2021 16:24, Zhang, Qi Z:
> > From: Thomas Monjalon <thomas@monjalon.net>
> > > 07/01/2021 13:47, Zhang, Qi Z:
> > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > 07/01/2021 10:32, Guo, Jia:
> > > > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > > 24/12/2020 07:59, Jeff Guo:
> > > > > > > > --- a/lib/librte_ethdev/rte_ethdev.h
> > > > > > > > +++ b/lib/librte_ethdev/rte_ethdev.h
> > > > > > > > @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
> > > > > > > >  	RTE_TUNNEL_TYPE_IP_IN_GRE,
> > > > > > > >  	RTE_L2_TUNNEL_TYPE_E_TAG,
> > > > > > > >  	RTE_TUNNEL_TYPE_VXLAN_GPE,
> > > > > > > > +	RTE_TUNNEL_TYPE_ECPRI,
> > > > > > > >  	RTE_TUNNEL_TYPE_MAX,
> > > > > > > >  };
> > > > > > >
> > > > > > > We tried to remove all these legacy API in DPDK 20.11.
> > > > > > > Andrew decided to not remove this one because it is not yet
> > > > > > > completely replaced by rte_flow in all drivers.
> > > > > > > However, I am against continuing to update this API.
> > > > > > > The opposite work should be done: migrate to rte_flow.
> > > > > >
> > > > > > Agree but seems that the legacy api and driver legacy
> > > > > > implementation still keep in this release, and there is no a
> > > > > > general way to replace the legacy by rte_flow right now.
> > > > >
> > > > > I think rte_flow is a complete replacement with more features.
> > > >
> > > > Thomas, I may not agree with this.
> > > >
> > > > Actually the "enum rte_eth_tunnel_type" is used by
> > > > rte_eth_dev_udp_tunnel_port_add A packet with specific dst udp
> > > > port will be recognized as a specific tunnel packet type (e.g.
> > > > vxlan, vxlan-gpe,
> > > ecpri...) In Intel NIC, the API actually changes the configuration
> > > of the packet parser in HW but not add a filter rule and I guess all
> > > other devices may enable it in a similar way.
> > > > so naturally it should be a device (port) level configuration but
> > > > not a rte_flow
> > > rule for match, encap, decap...
> > >
> > > I don't understand how it helps to identify an UDP port if there is
> > > no rule for this tunnel.
> > > What is the usage?
> >
> > Yes, in general It is a rule, it matches a udp packet's dst port and the action is
> "now the packet is identified as vxlan packet" then all other rte_flow rules that
> match for a vlxan as pattern will take effect.  but somehow, I think they are
> not rules in the same domain, just like we have dedicate API for mac/vlan filter,
> we'd better have a dedicate API for this also. ( RFC for Vxlan explains why we
> need this. https://tools.ietf.org/html/rfc7348).
> >
> > "Destination Port: IANA has assigned the value 4789 for the VXLAN UDP
> > port, and this value SHOULD be used by default as the destination UDP
> > port.  Some early implementations of VXLAN have used other values for
> > the destination port.  To enable interoperability with these
> > implementations, the destination port SHOULD be configurable."
> 
> Yes the port number is free.
> But isn't it more natural to specify this port number as part of the rte_flow
> rule?

I think if we have a rte_flow action type that can be used to set a packet's tunnel type xxx, like below 
#flow create eth/ipv4/udp port is 4789/... action set_tunnel_type VxLAN / end
then we may replace it with rte_flow, but I'm not sure if it's necessary, please share if you have a better idea.

BTW, are we going to move all other filter like mac , VLAN filter/strip/insert into rte_flow finally?
if that's the plan, though I don't have much inputs for this right now, but I think we may not need to prevent new features be added based on current API if it does not introduce more complexity and not break anything.


> 
> 
> 

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Ferruh Yigit]

On 1/8/2021 1:41 AM, Zhang, Qi Z wrote:
> 
> 
>> -----Original Message-----
>> From: Thomas Monjalon <thomas@monjalon.net>
>> Sent: Friday, January 8, 2021 12:59 AM
>> To: Guo, Jia <jia.guo@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>
>> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
>> <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
>> dev@dpdk.org; Yigit, Ferruh <ferruh.yigit@intel.com>;
>> andrew.rybchenko@oktetlabs.ru; orika@nvidia.com; getelson@nvidia.com;
>> Dodji Seketeli <dodji@redhat.com>
>> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
>>
>> 07/01/2021 16:24, Zhang, Qi Z:
>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>> 07/01/2021 13:47, Zhang, Qi Z:
>>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>>>> 07/01/2021 10:32, Guo, Jia:
>>>>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>>>>>> 24/12/2020 07:59, Jeff Guo:
>>>>>>>>> --- a/lib/librte_ethdev/rte_ethdev.h
>>>>>>>>> +++ b/lib/librte_ethdev/rte_ethdev.h
>>>>>>>>> @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
>>>>>>>>>   	RTE_TUNNEL_TYPE_IP_IN_GRE,
>>>>>>>>>   	RTE_L2_TUNNEL_TYPE_E_TAG,
>>>>>>>>>   	RTE_TUNNEL_TYPE_VXLAN_GPE,
>>>>>>>>> +	RTE_TUNNEL_TYPE_ECPRI,
>>>>>>>>>   	RTE_TUNNEL_TYPE_MAX,
>>>>>>>>>   };
>>>>>>>>
>>>>>>>> We tried to remove all these legacy API in DPDK 20.11.
>>>>>>>> Andrew decided to not remove this one because it is not yet
>>>>>>>> completely replaced by rte_flow in all drivers.
>>>>>>>> However, I am against continuing to update this API.
>>>>>>>> The opposite work should be done: migrate to rte_flow.
>>>>>>>
>>>>>>> Agree but seems that the legacy api and driver legacy
>>>>>>> implementation still keep in this release, and there is no a
>>>>>>> general way to replace the legacy by rte_flow right now.
>>>>>>
>>>>>> I think rte_flow is a complete replacement with more features.
>>>>>
>>>>> Thomas, I may not agree with this.
>>>>>
>>>>> Actually the "enum rte_eth_tunnel_type" is used by
>>>>> rte_eth_dev_udp_tunnel_port_add A packet with specific dst udp
>>>>> port will be recognized as a specific tunnel packet type (e.g.
>>>>> vxlan, vxlan-gpe,
>>>> ecpri...) In Intel NIC, the API actually changes the configuration
>>>> of the packet parser in HW but not add a filter rule and I guess all
>>>> other devices may enable it in a similar way.
>>>>> so naturally it should be a device (port) level configuration but
>>>>> not a rte_flow
>>>> rule for match, encap, decap...
>>>>
>>>> I don't understand how it helps to identify an UDP port if there is
>>>> no rule for this tunnel.
>>>> What is the usage?
>>>
>>> Yes, in general It is a rule, it matches a udp packet's dst port and the action is
>> "now the packet is identified as vxlan packet" then all other rte_flow rules that
>> match for a vlxan as pattern will take effect.  but somehow, I think they are
>> not rules in the same domain, just like we have dedicate API for mac/vlan filter,
>> we'd better have a dedicate API for this also. ( RFC for Vxlan explains why we
>> need this. https://tools.ietf.org/html/rfc7348).
>>>
>>> "Destination Port: IANA has assigned the value 4789 for the VXLAN UDP
>>> port, and this value SHOULD be used by default as the destination UDP
>>> port.  Some early implementations of VXLAN have used other values for
>>> the destination port.  To enable interoperability with these
>>> implementations, the destination port SHOULD be configurable."
>>
>> Yes the port number is free.
>> But isn't it more natural to specify this port number as part of the rte_flow
>> rule?
> 
> I think if we have a rte_flow action type that can be used to set a packet's tunnel type xxx, like below
> #flow create eth/ipv4/udp port is 4789/... action set_tunnel_type VxLAN / end
> then we may replace it with rte_flow, but I'm not sure if it's necessary, please share if you have a better idea.
> 

Isn't this more a device configuration than filtering, not sure about using 
rte_flow for this.

> BTW, are we going to move all other filter like mac , VLAN filter/strip/insert into rte_flow finally?
> if that's the plan, though I don't have much inputs for this right now, but I think we may not need to prevent new features be added based on current API if it does not introduce more complexity and not break anything.
> 
> 
>>
>>
>>
> 

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Andrew Rybchenko]

On 1/8/21 11:57 AM, Ferruh Yigit wrote:
> On 1/8/2021 1:41 AM, Zhang, Qi Z wrote:
>>
>>
>>> -----Original Message-----
>>> From: Thomas Monjalon <thomas@monjalon.net>
>>> Sent: Friday, January 8, 2021 12:59 AM
>>> To: Guo, Jia <jia.guo@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>
>>> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
>>> <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
>>> dev@dpdk.org; Yigit, Ferruh <ferruh.yigit@intel.com>;
>>> andrew.rybchenko@oktetlabs.ru; orika@nvidia.com; getelson@nvidia.com;
>>> Dodji Seketeli <dodji@redhat.com>
>>> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel 
>>> type for ecpri
>>>
>>> 07/01/2021 16:24, Zhang, Qi Z:
>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>>> 07/01/2021 13:47, Zhang, Qi Z:
>>>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>>>>> 07/01/2021 10:32, Guo, Jia:
>>>>>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>>>>>>> 24/12/2020 07:59, Jeff Guo:
>>>>>>>>>> --- a/lib/librte_ethdev/rte_ethdev.h
>>>>>>>>>> +++ b/lib/librte_ethdev/rte_ethdev.h
>>>>>>>>>> @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
>>>>>>>>>>       RTE_TUNNEL_TYPE_IP_IN_GRE,
>>>>>>>>>>       RTE_L2_TUNNEL_TYPE_E_TAG,
>>>>>>>>>>       RTE_TUNNEL_TYPE_VXLAN_GPE,
>>>>>>>>>> +    RTE_TUNNEL_TYPE_ECPRI,
>>>>>>>>>>       RTE_TUNNEL_TYPE_MAX,
>>>>>>>>>>   };
>>>>>>>>>
>>>>>>>>> We tried to remove all these legacy API in DPDK 20.11.
>>>>>>>>> Andrew decided to not remove this one because it is not yet
>>>>>>>>> completely replaced by rte_flow in all drivers.
>>>>>>>>> However, I am against continuing to update this API.
>>>>>>>>> The opposite work should be done: migrate to rte_flow.
>>>>>>>>
>>>>>>>> Agree but seems that the legacy api and driver legacy
>>>>>>>> implementation still keep in this release, and there is no a
>>>>>>>> general way to replace the legacy by rte_flow right now.
>>>>>>>
>>>>>>> I think rte_flow is a complete replacement with more features.
>>>>>>
>>>>>> Thomas, I may not agree with this.
>>>>>>
>>>>>> Actually the "enum rte_eth_tunnel_type" is used by
>>>>>> rte_eth_dev_udp_tunnel_port_add A packet with specific dst udp
>>>>>> port will be recognized as a specific tunnel packet type (e.g.
>>>>>> vxlan, vxlan-gpe,
>>>>> ecpri...) In Intel NIC, the API actually changes the configuration
>>>>> of the packet parser in HW but not add a filter rule and I guess all
>>>>> other devices may enable it in a similar way.
>>>>>> so naturally it should be a device (port) level configuration but
>>>>>> not a rte_flow
>>>>> rule for match, encap, decap...
>>>>>
>>>>> I don't understand how it helps to identify an UDP port if there is
>>>>> no rule for this tunnel.
>>>>> What is the usage?
>>>>
>>>> Yes, in general It is a rule, it matches a udp packet's dst port 
>>>> and the action is
>>> "now the packet is identified as vxlan packet" then all other 
>>> rte_flow rules that
>>> match for a vlxan as pattern will take effect.  but somehow, I think 
>>> they are
>>> not rules in the same domain, just like we have dedicate API for 
>>> mac/vlan filter,
>>> we'd better have a dedicate API for this also. ( RFC for Vxlan 
>>> explains why we
>>> need this. https://tools.ietf.org/html/rfc7348).
>>>>
>>>> "Destination Port: IANA has assigned the value 4789 for the VXLAN UDP
>>>> port, and this value SHOULD be used by default as the destination UDP
>>>> port.  Some early implementations of VXLAN have used other values for
>>>> the destination port.  To enable interoperability with these
>>>> implementations, the destination port SHOULD be configurable."
>>>
>>> Yes the port number is free.
>>> But isn't it more natural to specify this port number as part of the 
>>> rte_flow
>>> rule?
>>
>> I think if we have a rte_flow action type that can be used to set a 
>> packet's tunnel type xxx, like below
>> #flow create eth/ipv4/udp port is 4789/... action set_tunnel_type 
>> VxLAN / end
>> then we may replace it with rte_flow, but I'm not sure if it's 
>> necessary, please share if you have a better idea.
>>
>
> Isn't this more a device configuration than filtering, not sure about 
> using rte_flow for this.

+1

>> BTW, are we going to move all other filter like mac , VLAN 
>> filter/strip/insert into rte_flow finally?
>> if that's the plan, though I don't have much inputs for this right 
>> now, but I think we may not need to prevent new features be added 
>> based on current API if it does not introduce more complexity and not 
>> break anything.

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Thomas Monjalon]

08/01/2021 10:29, Andrew Rybchenko:
> On 1/8/21 11:57 AM, Ferruh Yigit wrote:
> > On 1/8/2021 1:41 AM, Zhang, Qi Z wrote:
> >> From: Thomas Monjalon <thomas@monjalon.net>
> >>> 07/01/2021 16:24, Zhang, Qi Z:
> >>>> From: Thomas Monjalon <thomas@monjalon.net>
> >>>>> 07/01/2021 13:47, Zhang, Qi Z:
> >>>>>> From: Thomas Monjalon <thomas@monjalon.net>
> >>>>>>> 07/01/2021 10:32, Guo, Jia:
> >>>>>>>> From: Thomas Monjalon <thomas@monjalon.net>
> >>>>>>>>> 24/12/2020 07:59, Jeff Guo:
> >>>>>>>>>> --- a/lib/librte_ethdev/rte_ethdev.h
> >>>>>>>>>> +++ b/lib/librte_ethdev/rte_ethdev.h
> >>>>>>>>>> @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
> >>>>>>>>>>       RTE_TUNNEL_TYPE_IP_IN_GRE,
> >>>>>>>>>>       RTE_L2_TUNNEL_TYPE_E_TAG,
> >>>>>>>>>>       RTE_TUNNEL_TYPE_VXLAN_GPE,
> >>>>>>>>>> +    RTE_TUNNEL_TYPE_ECPRI,
> >>>>>>>>>>       RTE_TUNNEL_TYPE_MAX,
> >>>>>>>>>>   };
> >>>>>>>>>
> >>>>>>>>> We tried to remove all these legacy API in DPDK 20.11.
> >>>>>>>>> Andrew decided to not remove this one because it is not yet
> >>>>>>>>> completely replaced by rte_flow in all drivers.
> >>>>>>>>> However, I am against continuing to update this API.
> >>>>>>>>> The opposite work should be done: migrate to rte_flow.
> >>>>>>>>
> >>>>>>>> Agree but seems that the legacy api and driver legacy
> >>>>>>>> implementation still keep in this release, and there is no a
> >>>>>>>> general way to replace the legacy by rte_flow right now.
> >>>>>>>
> >>>>>>> I think rte_flow is a complete replacement with more features.
> >>>>>>
> >>>>>> Thomas, I may not agree with this.
> >>>>>>
> >>>>>> Actually the "enum rte_eth_tunnel_type" is used by
> >>>>>> rte_eth_dev_udp_tunnel_port_add A packet with specific dst udp
> >>>>>> port will be recognized as a specific tunnel packet type (e.g.
> >>>>>> vxlan, vxlan-gpe,
> >>>>> ecpri...) In Intel NIC, the API actually changes the configuration
> >>>>> of the packet parser in HW but not add a filter rule and I guess all
> >>>>> other devices may enable it in a similar way.
> >>>>>> so naturally it should be a device (port) level configuration but
> >>>>>> not a rte_flow
> >>>>> rule for match, encap, decap...
> >>>>>
> >>>>> I don't understand how it helps to identify an UDP port if there is
> >>>>> no rule for this tunnel.
> >>>>> What is the usage?
> >>>>
> >>>> Yes, in general It is a rule, it matches a udp packet's dst port 
> >>>> and the action is
> >>> "now the packet is identified as vxlan packet" then all other 
> >>> rte_flow rules that
> >>> match for a vlxan as pattern will take effect.  but somehow, I think 
> >>> they are
> >>> not rules in the same domain, just like we have dedicate API for 
> >>> mac/vlan filter,
> >>> we'd better have a dedicate API for this also. ( RFC for Vxlan 
> >>> explains why we
> >>> need this. https://tools.ietf.org/html/rfc7348).
> >>>>
> >>>> "Destination Port: IANA has assigned the value 4789 for the VXLAN UDP
> >>>> port, and this value SHOULD be used by default as the destination UDP
> >>>> port.  Some early implementations of VXLAN have used other values for
> >>>> the destination port.  To enable interoperability with these
> >>>> implementations, the destination port SHOULD be configurable."
> >>>
> >>> Yes the port number is free.
> >>> But isn't it more natural to specify this port number as part of the 
> >>> rte_flow
> >>> rule?
> >>
> >> I think if we have a rte_flow action type that can be used to set a 
> >> packet's tunnel type xxx, like below
> >> #flow create eth/ipv4/udp port is 4789/... action set_tunnel_type 
> >> VxLAN / end
> >> then we may replace it with rte_flow, but I'm not sure if it's 
> >> necessary, please share if you have a better idea.

Of course we can specify the UDP port in rte_flow rule.
Please check rte_flow_item_udp.
That's a basic of rte_flow.


> > Isn't this more a device configuration than filtering, not sure about 
> > using rte_flow for this.
> 
> +1

A device configuration? No, setting an UDP port is a stack configuration.

 
> >> BTW, are we going to move all other filter like mac , VLAN 
> >> filter/strip/insert into rte_flow finally?

Yes I think it should be the direction.
All of this can be achieved with rte_flow.


> >> if that's the plan, though I don't have much inputs for this right 
> >> now, but I think we may not need to prevent new features be added 
> >> based on current API if it does not introduce more complexity and not 
> >> break anything.

If we continue updating old API, we are just forking ourself:
having 2 APIs for the same feature is a non-sense.
We must remove APIs which are superseded by rte_flow.

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Zhang, Qi Z]

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Friday, January 8, 2021 6:36 PM
> To: Yigit, Ferruh <ferruh.yigit@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>;
> Guo, Jia <jia.guo@intel.com>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>
> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
> <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
> dev@dpdk.org; orika@nvidia.com; getelson@nvidia.com
> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
> 
> 08/01/2021 10:29, Andrew Rybchenko:
> > On 1/8/21 11:57 AM, Ferruh Yigit wrote:
> > > On 1/8/2021 1:41 AM, Zhang, Qi Z wrote:
> > >> From: Thomas Monjalon <thomas@monjalon.net>
> > >>> 07/01/2021 16:24, Zhang, Qi Z:
> > >>>> From: Thomas Monjalon <thomas@monjalon.net>
> > >>>>> 07/01/2021 13:47, Zhang, Qi Z:
> > >>>>>> From: Thomas Monjalon <thomas@monjalon.net>
> > >>>>>>> 07/01/2021 10:32, Guo, Jia:
> > >>>>>>>> From: Thomas Monjalon <thomas@monjalon.net>
> > >>>>>>>>> 24/12/2020 07:59, Jeff Guo:
> > >>>>>>>>>> --- a/lib/librte_ethdev/rte_ethdev.h
> > >>>>>>>>>> +++ b/lib/librte_ethdev/rte_ethdev.h
> > >>>>>>>>>> @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
> > >>>>>>>>>>       RTE_TUNNEL_TYPE_IP_IN_GRE,
> > >>>>>>>>>>       RTE_L2_TUNNEL_TYPE_E_TAG,
> > >>>>>>>>>>       RTE_TUNNEL_TYPE_VXLAN_GPE,
> > >>>>>>>>>> +    RTE_TUNNEL_TYPE_ECPRI,
> > >>>>>>>>>>       RTE_TUNNEL_TYPE_MAX,
> > >>>>>>>>>>   };
> > >>>>>>>>>
> > >>>>>>>>> We tried to remove all these legacy API in DPDK 20.11.
> > >>>>>>>>> Andrew decided to not remove this one because it is not yet
> > >>>>>>>>> completely replaced by rte_flow in all drivers.
> > >>>>>>>>> However, I am against continuing to update this API.
> > >>>>>>>>> The opposite work should be done: migrate to rte_flow.
> > >>>>>>>>
> > >>>>>>>> Agree but seems that the legacy api and driver legacy
> > >>>>>>>> implementation still keep in this release, and there is no a
> > >>>>>>>> general way to replace the legacy by rte_flow right now.
> > >>>>>>>
> > >>>>>>> I think rte_flow is a complete replacement with more features.
> > >>>>>>
> > >>>>>> Thomas, I may not agree with this.
> > >>>>>>
> > >>>>>> Actually the "enum rte_eth_tunnel_type" is used by
> > >>>>>> rte_eth_dev_udp_tunnel_port_add A packet with specific dst udp
> > >>>>>> port will be recognized as a specific tunnel packet type (e.g.
> > >>>>>> vxlan, vxlan-gpe,
> > >>>>> ecpri...) In Intel NIC, the API actually changes the
> > >>>>> configuration of the packet parser in HW but not add a filter
> > >>>>> rule and I guess all other devices may enable it in a similar way.
> > >>>>>> so naturally it should be a device (port) level configuration
> > >>>>>> but not a rte_flow
> > >>>>> rule for match, encap, decap...
> > >>>>>
> > >>>>> I don't understand how it helps to identify an UDP port if there
> > >>>>> is no rule for this tunnel.
> > >>>>> What is the usage?
> > >>>>
> > >>>> Yes, in general It is a rule, it matches a udp packet's dst port
> > >>>> and the action is
> > >>> "now the packet is identified as vxlan packet" then all other
> > >>> rte_flow rules that match for a vlxan as pattern will take effect.
> > >>> but somehow, I think they are not rules in the same domain, just
> > >>> like we have dedicate API for mac/vlan filter, we'd better have a
> > >>> dedicate API for this also. ( RFC for Vxlan explains why we need
> > >>> this. https://tools.ietf.org/html/rfc7348).
> > >>>>
> > >>>> "Destination Port: IANA has assigned the value 4789 for the VXLAN
> > >>>> UDP port, and this value SHOULD be used by default as the
> > >>>> destination UDP port.  Some early implementations of VXLAN have
> > >>>> used other values for the destination port.  To enable
> > >>>> interoperability with these implementations, the destination port
> SHOULD be configurable."
> > >>>
> > >>> Yes the port number is free.
> > >>> But isn't it more natural to specify this port number as part of
> > >>> the rte_flow rule?
> > >>
> > >> I think if we have a rte_flow action type that can be used to set a
> > >> packet's tunnel type xxx, like below #flow create eth/ipv4/udp port
> > >> is 4789/... action set_tunnel_type VxLAN / end then we may replace
> > >> it with rte_flow, but I'm not sure if it's necessary, please share
> > >> if you have a better idea.
> 
> Of course we can specify the UDP port in rte_flow rule.
> Please check rte_flow_item_udp.
> That's a basic of rte_flow.

Its not about the pattern match, it's about the action, what we need is a rte_flow action to "define a packet's tunnel type", but we don't have.

#flow create eth/ipv4/udp port is 4789/... action set_tunnel_type VxLAN

I think rte_eth_dev_udp_tunnel_port_add does this job well already, if we plan to move it to rte_flow, at least we need a replacement solution.

> 
> 
> > > Isn't this more a device configuration than filtering, not sure
> > > about using rte_flow for this.
> >
> > +1
> 
> A device configuration? No, setting an UDP port is a stack configuration.
> 
> 
> > >> BTW, are we going to move all other filter like mac , VLAN
> > >> filter/strip/insert into rte_flow finally?
> 
> Yes I think it should be the direction.
> All of this can be achieved with rte_flow.
> 
> 
> > >> if that's the plan, though I don't have much inputs for this right
> > >> now, but I think we may not need to prevent new features be added
> > >> based on current API if it does not introduce more complexity and
> > >> not break anything.
> 
> If we continue updating old API, we are just forking ourself:
> having 2 APIs for the same feature is a non-sense.
> We must remove APIs which are superseded by rte_flow.
> 

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Ori Kam]

Hi,

> -----Original Message-----
> From: Zhang, Qi Z <qi.z.zhang@intel.com>
> Sent: Saturday, January 9, 2021 3:01 AM
> Subject: RE: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
> 
> 
> 
> > -----Original Message-----
> > From: Thomas Monjalon <thomas@monjalon.net>
> > Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for
> ecpri
> >
> > 08/01/2021 10:29, Andrew Rybchenko:
> > > On 1/8/21 11:57 AM, Ferruh Yigit wrote:
> > > > On 1/8/2021 1:41 AM, Zhang, Qi Z wrote:
> > > >> From: Thomas Monjalon <thomas@monjalon.net>
> > > >>> 07/01/2021 16:24, Zhang, Qi Z:
> > > >>>> From: Thomas Monjalon <thomas@monjalon.net>
> > > >>>>> 07/01/2021 13:47, Zhang, Qi Z:
> > > >>>>>> From: Thomas Monjalon <thomas@monjalon.net>
> > > >>>>>>> 07/01/2021 10:32, Guo, Jia:
> > > >>>>>>>> From: Thomas Monjalon <thomas@monjalon.net>
> > > >>>>>>>>> 24/12/2020 07:59, Jeff Guo:
> > > >>>>>>>>>> --- a/lib/librte_ethdev/rte_ethdev.h
> > > >>>>>>>>>> +++ b/lib/librte_ethdev/rte_ethdev.h
> > > >>>>>>>>>> @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
> > > >>>>>>>>>>       RTE_TUNNEL_TYPE_IP_IN_GRE,
> > > >>>>>>>>>>       RTE_L2_TUNNEL_TYPE_E_TAG,
> > > >>>>>>>>>>       RTE_TUNNEL_TYPE_VXLAN_GPE,
> > > >>>>>>>>>> +    RTE_TUNNEL_TYPE_ECPRI,
> > > >>>>>>>>>>       RTE_TUNNEL_TYPE_MAX,
> > > >>>>>>>>>>   };
> > > >>>>>>>>>
> > > >>>>>>>>> We tried to remove all these legacy API in DPDK 20.11.
> > > >>>>>>>>> Andrew decided to not remove this one because it is not yet
> > > >>>>>>>>> completely replaced by rte_flow in all drivers.
> > > >>>>>>>>> However, I am against continuing to update this API.
> > > >>>>>>>>> The opposite work should be done: migrate to rte_flow.
> > > >>>>>>>>
> > > >>>>>>>> Agree but seems that the legacy api and driver legacy
> > > >>>>>>>> implementation still keep in this release, and there is no a
> > > >>>>>>>> general way to replace the legacy by rte_flow right now.
> > > >>>>>>>
> > > >>>>>>> I think rte_flow is a complete replacement with more features.
> > > >>>>>>
> > > >>>>>> Thomas, I may not agree with this.
> > > >>>>>>
> > > >>>>>> Actually the "enum rte_eth_tunnel_type" is used by
> > > >>>>>> rte_eth_dev_udp_tunnel_port_add A packet with specific dst udp
> > > >>>>>> port will be recognized as a specific tunnel packet type (e.g.
> > > >>>>>> vxlan, vxlan-gpe,
> > > >>>>> ecpri...) In Intel NIC, the API actually changes the
> > > >>>>> configuration of the packet parser in HW but not add a filter
> > > >>>>> rule and I guess all other devices may enable it in a similar way.
> > > >>>>>> so naturally it should be a device (port) level configuration
> > > >>>>>> but not a rte_flow
> > > >>>>> rule for match, encap, decap...
> > > >>>>>
> > > >>>>> I don't understand how it helps to identify an UDP port if there
> > > >>>>> is no rule for this tunnel.
> > > >>>>> What is the usage?
> > > >>>>
> > > >>>> Yes, in general It is a rule, it matches a udp packet's dst port
> > > >>>> and the action is
> > > >>> "now the packet is identified as vxlan packet" then all other
> > > >>> rte_flow rules that match for a vlxan as pattern will take effect.
> > > >>> but somehow, I think they are not rules in the same domain, just
> > > >>> like we have dedicate API for mac/vlan filter, we'd better have a
> > > >>> dedicate API for this also. ( RFC for Vxlan explains why we need
> > > >>> this.
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf
> .org%2Fhtml%2Frfc7348&amp;data=04%7C01%7Corika%40nvidia.com%7C46b2
> d8f48944422f0d9008d8b43a2293%7C43083d15727340c1b7db39efd9ccc17a%7
> C0%7C0%7C637457509081543237%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&a
> mp;sdata=RYWFMjuxkcUZ982kK2s44tBAjf%2FTkDyaa7VEybCtxOo%3D&amp;res
> erved=0).
> > > >>>>
> > > >>>> "Destination Port: IANA has assigned the value 4789 for the VXLAN
> > > >>>> UDP port, and this value SHOULD be used by default as the
> > > >>>> destination UDP port.  Some early implementations of VXLAN have
> > > >>>> used other values for the destination port.  To enable
> > > >>>> interoperability with these implementations, the destination port
> > SHOULD be configurable."
> > > >>>
> > > >>> Yes the port number is free.
> > > >>> But isn't it more natural to specify this port number as part of
> > > >>> the rte_flow rule?
> > > >>
> > > >> I think if we have a rte_flow action type that can be used to set a
> > > >> packet's tunnel type xxx, like below #flow create eth/ipv4/udp port
> > > >> is 4789/... action set_tunnel_type VxLAN / end then we may replace
> > > >> it with rte_flow, but I'm not sure if it's necessary, please share
> > > >> if you have a better idea.
> >
> > Of course we can specify the UDP port in rte_flow rule.
> > Please check rte_flow_item_udp.
> > That's a basic of rte_flow.
> 
> Its not about the pattern match, it's about the action, what we need is a
> rte_flow action to "define a packet's tunnel type", but we don't have.
> 
> #flow create eth/ipv4/udp port is 4789/... action set_tunnel_type VxLAN
> 
> I think rte_eth_dev_udp_tunnel_port_add does this job well already, if we plan
> to move it to rte_flow, at least we need a replacement solution.
> 

Let me see if I understand it correctly.
In your case, the issue is that you need to configure the HW to parse the packet correctly right?
It is not about the matching it is about the configuration of the HW, you wish to tell
the HW that the packet should be parsed by different means correct?

If this is the case it sounds to me that you should use rte_flow and if the 
user adds the following rule:
#flow create pattern eth / ivp4 / udp port is 4789 / .. action .....
You simply need to configure your HW to support the ecpri configuration.


> >
> >
> > > > Isn't this more a device configuration than filtering, not sure
> > > > about using rte_flow for this.
> > >
> > > +1
> >
> > A device configuration? No, setting an UDP port is a stack configuration.
> >
> >
> > > >> BTW, are we going to move all other filter like mac , VLAN
> > > >> filter/strip/insert into rte_flow finally?
> >
> > Yes I think it should be the direction.
> > All of this can be achieved with rte_flow.
> >
> >
> > > >> if that's the plan, though I don't have much inputs for this right
> > > >> now, but I think we may not need to prevent new features be added
> > > >> based on current API if it does not introduce more complexity and
> > > >> not break anything.
> >
> > If we continue updating old API, we are just forking ourself:
> > having 2 APIs for the same feature is a non-sense.
> > We must remove APIs which are superseded by rte_flow.
> >

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Thomas Monjalon]

10/01/2021 11:46, Ori Kam:
> Hi,
> 
> > -----Original Message-----
> > From: Zhang, Qi Z <qi.z.zhang@intel.com>
> > Sent: Saturday, January 9, 2021 3:01 AM
> > Subject: RE: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > > Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for
> > ecpri
> > >
> > > 08/01/2021 10:29, Andrew Rybchenko:
> > > > On 1/8/21 11:57 AM, Ferruh Yigit wrote:
> > > > > On 1/8/2021 1:41 AM, Zhang, Qi Z wrote:
> > > > >> From: Thomas Monjalon <thomas@monjalon.net>
> > > > >>> 07/01/2021 16:24, Zhang, Qi Z:
> > > > >>>> From: Thomas Monjalon <thomas@monjalon.net>
> > > > >>>>> 07/01/2021 13:47, Zhang, Qi Z:
> > > > >>>>>> From: Thomas Monjalon <thomas@monjalon.net>
> > > > >>>>>>> 07/01/2021 10:32, Guo, Jia:
> > > > >>>>>>>> From: Thomas Monjalon <thomas@monjalon.net>
> > > > >>>>>>>>> 24/12/2020 07:59, Jeff Guo:
> > > > >>>>>>>>>> --- a/lib/librte_ethdev/rte_ethdev.h
> > > > >>>>>>>>>> +++ b/lib/librte_ethdev/rte_ethdev.h
> > > > >>>>>>>>>> @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
> > > > >>>>>>>>>>       RTE_TUNNEL_TYPE_IP_IN_GRE,
> > > > >>>>>>>>>>       RTE_L2_TUNNEL_TYPE_E_TAG,
> > > > >>>>>>>>>>       RTE_TUNNEL_TYPE_VXLAN_GPE,
> > > > >>>>>>>>>> +    RTE_TUNNEL_TYPE_ECPRI,
> > > > >>>>>>>>>>       RTE_TUNNEL_TYPE_MAX,
> > > > >>>>>>>>>>   };
> > > > >>>>>>>>>
> > > > >>>>>>>>> We tried to remove all these legacy API in DPDK 20.11.
> > > > >>>>>>>>> Andrew decided to not remove this one because it is not yet
> > > > >>>>>>>>> completely replaced by rte_flow in all drivers.
> > > > >>>>>>>>> However, I am against continuing to update this API.
> > > > >>>>>>>>> The opposite work should be done: migrate to rte_flow.
> > > > >>>>>>>>
> > > > >>>>>>>> Agree but seems that the legacy api and driver legacy
> > > > >>>>>>>> implementation still keep in this release, and there is no a
> > > > >>>>>>>> general way to replace the legacy by rte_flow right now.
> > > > >>>>>>>
> > > > >>>>>>> I think rte_flow is a complete replacement with more features.
> > > > >>>>>>
> > > > >>>>>> Thomas, I may not agree with this.
> > > > >>>>>>
> > > > >>>>>> Actually the "enum rte_eth_tunnel_type" is used by
> > > > >>>>>> rte_eth_dev_udp_tunnel_port_add A packet with specific dst udp
> > > > >>>>>> port will be recognized as a specific tunnel packet type (e.g.
> > > > >>>>>> vxlan, vxlan-gpe,
> > > > >>>>> ecpri...) In Intel NIC, the API actually changes the
> > > > >>>>> configuration of the packet parser in HW but not add a filter
> > > > >>>>> rule and I guess all other devices may enable it in a similar way.
> > > > >>>>>> so naturally it should be a device (port) level configuration
> > > > >>>>>> but not a rte_flow
> > > > >>>>> rule for match, encap, decap...
> > > > >>>>>
> > > > >>>>> I don't understand how it helps to identify an UDP port if there
> > > > >>>>> is no rule for this tunnel.
> > > > >>>>> What is the usage?
> > > > >>>>
> > > > >>>> Yes, in general It is a rule, it matches a udp packet's dst port
> > > > >>>> and the action is
> > > > >>> "now the packet is identified as vxlan packet" then all other
> > > > >>> rte_flow rules that match for a vlxan as pattern will take effect.
> > > > >>> but somehow, I think they are not rules in the same domain, just
> > > > >>> like we have dedicate API for mac/vlan filter, we'd better have a
> > > > >>> dedicate API for this also. ( RFC for Vxlan explains why we need
> > > > >>> this.
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf
> > .org%2Fhtml%2Frfc7348&amp;data=04%7C01%7Corika%40nvidia.com%7C46b2
> > d8f48944422f0d9008d8b43a2293%7C43083d15727340c1b7db39efd9ccc17a%7
> > C0%7C0%7C637457509081543237%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&a
> > mp;sdata=RYWFMjuxkcUZ982kK2s44tBAjf%2FTkDyaa7VEybCtxOo%3D&amp;res
> > erved=0).
> > > > >>>>
> > > > >>>> "Destination Port: IANA has assigned the value 4789 for the VXLAN
> > > > >>>> UDP port, and this value SHOULD be used by default as the
> > > > >>>> destination UDP port.  Some early implementations of VXLAN have
> > > > >>>> used other values for the destination port.  To enable
> > > > >>>> interoperability with these implementations, the destination port
> > > SHOULD be configurable."
> > > > >>>
> > > > >>> Yes the port number is free.
> > > > >>> But isn't it more natural to specify this port number as part of
> > > > >>> the rte_flow rule?
> > > > >>
> > > > >> I think if we have a rte_flow action type that can be used to set a
> > > > >> packet's tunnel type xxx, like below #flow create eth/ipv4/udp port
> > > > >> is 4789/... action set_tunnel_type VxLAN / end then we may replace
> > > > >> it with rte_flow, but I'm not sure if it's necessary, please share
> > > > >> if you have a better idea.
> > >
> > > Of course we can specify the UDP port in rte_flow rule.
> > > Please check rte_flow_item_udp.
> > > That's a basic of rte_flow.
> > 
> > Its not about the pattern match, it's about the action, what we need is a
> > rte_flow action to "define a packet's tunnel type", but we don't have.

A packet type alone is meaningless.
It is always associated to an action, this is what rte_flow does.


> > #flow create eth/ipv4/udp port is 4789/... action set_tunnel_type VxLAN
> > 
> > I think rte_eth_dev_udp_tunnel_port_add does this job well already, if we plan
> > to move it to rte_flow, at least we need a replacement solution.

The documentation does not say why it is useful.
With rte_flow you don't need it because a flow is specified with its action.


> Let me see if I understand it correctly.
> In your case, the issue is that you need to configure the HW to parse the packet correctly right?
> It is not about the matching it is about the configuration of the HW, you wish to tell
> the HW that the packet should be parsed by different means correct?
> 
> If this is the case it sounds to me that you should use rte_flow and if the 
> user adds the following rule:
> #flow create pattern eth / ivp4 / udp port is 4789 / .. action .....
> You simply need to configure your HW to support the ecpri configuration.
> 
> 
> > >
> > >
> > > > > Isn't this more a device configuration than filtering, not sure
> > > > > about using rte_flow for this.
> > > >
> > > > +1
> > >
> > > A device configuration? No, setting an UDP port is a stack configuration.
> > >
> > >
> > > > >> BTW, are we going to move all other filter like mac , VLAN
> > > > >> filter/strip/insert into rte_flow finally?
> > >
> > > Yes I think it should be the direction.
> > > All of this can be achieved with rte_flow.
> > >
> > >
> > > > >> if that's the plan, though I don't have much inputs for this right
> > > > >> now, but I think we may not need to prevent new features be added
> > > > >> based on current API if it does not introduce more complexity and
> > > > >> not break anything.
> > >
> > > If we continue updating old API, we are just forking ourself:
> > > having 2 APIs for the same feature is a non-sense.
> > > We must remove APIs which are superseded by rte_flow.
> > >
> 
> 

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Zhang, Qi Z]

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Monday, January 11, 2021 5:24 PM
> To: Zhang, Qi Z <qi.z.zhang@intel.com>; Yigit, Ferruh <ferruh.yigit@intel.com>;
> Guo, Jia <jia.guo@intel.com>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; Ori Kam <orika@nvidia.com>
> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
> <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
> dev@dpdk.org; Gregory Etelson <getelson@nvidia.com>
> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
> 
> 10/01/2021 11:46, Ori Kam:
> > Hi,
> >
> > > -----Original Message-----
> > > From: Zhang, Qi Z <qi.z.zhang@intel.com>
> > > Sent: Saturday, January 9, 2021 3:01 AM
> > > Subject: RE: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel
> > > type for ecpri
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel
> > > > type for
> > > ecpri
> > > >
> > > > 08/01/2021 10:29, Andrew Rybchenko:
> > > > > On 1/8/21 11:57 AM, Ferruh Yigit wrote:
> > > > > > On 1/8/2021 1:41 AM, Zhang, Qi Z wrote:
> > > > > >> From: Thomas Monjalon <thomas@monjalon.net>
> > > > > >>> 07/01/2021 16:24, Zhang, Qi Z:
> > > > > >>>> From: Thomas Monjalon <thomas@monjalon.net>
> > > > > >>>>> 07/01/2021 13:47, Zhang, Qi Z:
> > > > > >>>>>> From: Thomas Monjalon <thomas@monjalon.net>
> > > > > >>>>>>> 07/01/2021 10:32, Guo, Jia:
> > > > > >>>>>>>> From: Thomas Monjalon <thomas@monjalon.net>
> > > > > >>>>>>>>> 24/12/2020 07:59, Jeff Guo:
> > > > > >>>>>>>>>> --- a/lib/librte_ethdev/rte_ethdev.h
> > > > > >>>>>>>>>> +++ b/lib/librte_ethdev/rte_ethdev.h
> > > > > >>>>>>>>>> @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
> > > > > >>>>>>>>>>       RTE_TUNNEL_TYPE_IP_IN_GRE,
> > > > > >>>>>>>>>>       RTE_L2_TUNNEL_TYPE_E_TAG,
> > > > > >>>>>>>>>>       RTE_TUNNEL_TYPE_VXLAN_GPE,
> > > > > >>>>>>>>>> +    RTE_TUNNEL_TYPE_ECPRI,
> > > > > >>>>>>>>>>       RTE_TUNNEL_TYPE_MAX,
> > > > > >>>>>>>>>>   };
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> We tried to remove all these legacy API in DPDK 20.11.
> > > > > >>>>>>>>> Andrew decided to not remove this one because it is
> > > > > >>>>>>>>> not yet completely replaced by rte_flow in all drivers.
> > > > > >>>>>>>>> However, I am against continuing to update this API.
> > > > > >>>>>>>>> The opposite work should be done: migrate to rte_flow.
> > > > > >>>>>>>>
> > > > > >>>>>>>> Agree but seems that the legacy api and driver legacy
> > > > > >>>>>>>> implementation still keep in this release, and there is
> > > > > >>>>>>>> no a general way to replace the legacy by rte_flow right now.
> > > > > >>>>>>>
> > > > > >>>>>>> I think rte_flow is a complete replacement with more features.
> > > > > >>>>>>
> > > > > >>>>>> Thomas, I may not agree with this.
> > > > > >>>>>>
> > > > > >>>>>> Actually the "enum rte_eth_tunnel_type" is used by
> > > > > >>>>>> rte_eth_dev_udp_tunnel_port_add A packet with specific
> > > > > >>>>>> dst udp port will be recognized as a specific tunnel packet type
> (e.g.
> > > > > >>>>>> vxlan, vxlan-gpe,
> > > > > >>>>> ecpri...) In Intel NIC, the API actually changes the
> > > > > >>>>> configuration of the packet parser in HW but not add a
> > > > > >>>>> filter rule and I guess all other devices may enable it in a similar
> way.
> > > > > >>>>>> so naturally it should be a device (port) level
> > > > > >>>>>> configuration but not a rte_flow
> > > > > >>>>> rule for match, encap, decap...
> > > > > >>>>>
> > > > > >>>>> I don't understand how it helps to identify an UDP port if
> > > > > >>>>> there is no rule for this tunnel.
> > > > > >>>>> What is the usage?
> > > > > >>>>
> > > > > >>>> Yes, in general It is a rule, it matches a udp packet's dst
> > > > > >>>> port and the action is
> > > > > >>> "now the packet is identified as vxlan packet" then all
> > > > > >>> other rte_flow rules that match for a vlxan as pattern will take
> effect.
> > > > > >>> but somehow, I think they are not rules in the same domain,
> > > > > >>> just like we have dedicate API for mac/vlan filter, we'd
> > > > > >>> better have a dedicate API for this also. ( RFC for Vxlan
> > > > > >>> explains why we need this.
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fto
> > > ols.ietf
> > > .org%2Fhtml%2Frfc7348&amp;data=04%7C01%7Corika%40nvidia.com%7C
> 46b2
> > >
> d8f48944422f0d9008d8b43a2293%7C43083d15727340c1b7db39efd9ccc17a
> %7
> > >
> C0%7C0%7C637457509081543237%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC
> > >
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&a
> > >
> mp;sdata=RYWFMjuxkcUZ982kK2s44tBAjf%2FTkDyaa7VEybCtxOo%3D&amp;r
> es
> > > erved=0).
> > > > > >>>>
> > > > > >>>> "Destination Port: IANA has assigned the value 4789 for the
> > > > > >>>> VXLAN UDP port, and this value SHOULD be used by default as
> > > > > >>>> the destination UDP port.  Some early implementations of
> > > > > >>>> VXLAN have used other values for the destination port.  To
> > > > > >>>> enable interoperability with these implementations, the
> > > > > >>>> destination port
> > > > SHOULD be configurable."
> > > > > >>>
> > > > > >>> Yes the port number is free.
> > > > > >>> But isn't it more natural to specify this port number as
> > > > > >>> part of the rte_flow rule?
> > > > > >>
> > > > > >> I think if we have a rte_flow action type that can be used to
> > > > > >> set a packet's tunnel type xxx, like below #flow create
> > > > > >> eth/ipv4/udp port is 4789/... action set_tunnel_type VxLAN /
> > > > > >> end then we may replace it with rte_flow, but I'm not sure if
> > > > > >> it's necessary, please share if you have a better idea.
> > > >
> > > > Of course we can specify the UDP port in rte_flow rule.
> > > > Please check rte_flow_item_udp.
> > > > That's a basic of rte_flow.
> > >
> > > Its not about the pattern match, it's about the action, what we need
> > > is a rte_flow action to "define a packet's tunnel type", but we don't have.
> 
> A packet type alone is meaningless.
> It is always associated to an action, this is what rte_flow does.

As I mentioned in previous, this is a device (port) level configuration, so it can only be configured by a PF driver or a privileged VF base on our security model.
A typical usage in a NFV environment could be:

1. A privileged VF (e.g. ice_dcf PMD) use rte_eth_dev_udp_tunnel_port_add to create tunnel port for eCPRI, them this will impact on all VFs in the same PF.
2. A normal VF driver can create rte_flow rule that match specific patch for queue steering or apply RSS for eCPRI packets, but it DON'T have the permission to define the tunnel port.

So it does not help to have a rte_flow that match dst udp port as tunnel while have an action in the same rule.


> 
> 
> > > #flow create eth/ipv4/udp port is 4789/... action set_tunnel_type
> > > VxLAN
> > >
> > > I think rte_eth_dev_udp_tunnel_port_add does this job well already,
> > > if we plan to move it to rte_flow, at least we need a replacement solution.
> 
> The documentation does not say why it is useful.
> With rte_flow you don't need it because a flow is specified with its action.
> 
> 
> > Let me see if I understand it correctly.
> > In your case, the issue is that you need to configure the HW to parse the
> packet correctly right?
> > It is not about the matching it is about the configuration of the HW,
> > you wish to tell the HW that the packet should be parsed by different means
> correct?
> >
> > If this is the case it sounds to me that you should use rte_flow and
> > if the user adds the following rule:
> > #flow create pattern eth / ivp4 / udp port is 4789 / .. action .....
> > You simply need to configure your HW to support the ecpri configuration.
> >
> >
> > > >
> > > >
> > > > > > Isn't this more a device configuration than filtering, not
> > > > > > sure about using rte_flow for this.
> > > > >
> > > > > +1
> > > >
> > > > A device configuration? No, setting an UDP port is a stack configuration.
> > > >
> > > >
> > > > > >> BTW, are we going to move all other filter like mac , VLAN
> > > > > >> filter/strip/insert into rte_flow finally?
> > > >
> > > > Yes I think it should be the direction.
> > > > All of this can be achieved with rte_flow.
> > > >
> > > >
> > > > > >> if that's the plan, though I don't have much inputs for this
> > > > > >> right now, but I think we may not need to prevent new
> > > > > >> features be added based on current API if it does not
> > > > > >> introduce more complexity and not break anything.
> > > >
> > > > If we continue updating old API, we are just forking ourself:
> > > > having 2 APIs for the same feature is a non-sense.
> > > > We must remove APIs which are superseded by rte_flow.
> > > >
> >
> >
> 
> 
> 
> 

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Thomas Monjalon]

11/01/2021 12:26, Zhang, Qi Z:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 10/01/2021 11:46, Ori Kam:
> > > From: Zhang, Qi Z <qi.z.zhang@intel.com>
> > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > 08/01/2021 10:29, Andrew Rybchenko:
> > > > > > On 1/8/21 11:57 AM, Ferruh Yigit wrote:
> > > > > > > On 1/8/2021 1:41 AM, Zhang, Qi Z wrote:
> > > > > > >> From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > >>> 07/01/2021 16:24, Zhang, Qi Z:
> > > > > > >>>> From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > >>>>> 07/01/2021 13:47, Zhang, Qi Z:
> > > > > > >>>>>> From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > >>>>>>> 07/01/2021 10:32, Guo, Jia:
> > > > > > >>>>>>>> From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > >>>>>>>>> 24/12/2020 07:59, Jeff Guo:
> > > > > > >>>>>>>>>> --- a/lib/librte_ethdev/rte_ethdev.h
> > > > > > >>>>>>>>>> +++ b/lib/librte_ethdev/rte_ethdev.h
> > > > > > >>>>>>>>>> @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
> > > > > > >>>>>>>>>>       RTE_TUNNEL_TYPE_IP_IN_GRE,
> > > > > > >>>>>>>>>>       RTE_L2_TUNNEL_TYPE_E_TAG,
> > > > > > >>>>>>>>>>       RTE_TUNNEL_TYPE_VXLAN_GPE,
> > > > > > >>>>>>>>>> +    RTE_TUNNEL_TYPE_ECPRI,
> > > > > > >>>>>>>>>>       RTE_TUNNEL_TYPE_MAX,
> > > > > > >>>>>>>>>>   };
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> We tried to remove all these legacy API in DPDK 20.11.
> > > > > > >>>>>>>>> Andrew decided to not remove this one because it is
> > > > > > >>>>>>>>> not yet completely replaced by rte_flow in all drivers.
> > > > > > >>>>>>>>> However, I am against continuing to update this API.
> > > > > > >>>>>>>>> The opposite work should be done: migrate to rte_flow.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Agree but seems that the legacy api and driver legacy
> > > > > > >>>>>>>> implementation still keep in this release, and there is
> > > > > > >>>>>>>> no a general way to replace the legacy by rte_flow right now.
> > > > > > >>>>>>>
> > > > > > >>>>>>> I think rte_flow is a complete replacement with more features.
> > > > > > >>>>>>
> > > > > > >>>>>> Thomas, I may not agree with this.
> > > > > > >>>>>>
> > > > > > >>>>>> Actually the "enum rte_eth_tunnel_type" is used by
> > > > > > >>>>>> rte_eth_dev_udp_tunnel_port_add A packet with specific
> > > > > > >>>>>> dst udp port will be recognized as a specific tunnel packet type
> > (e.g.
> > > > > > >>>>>> vxlan, vxlan-gpe,
> > > > > > >>>>> ecpri...) In Intel NIC, the API actually changes the
> > > > > > >>>>> configuration of the packet parser in HW but not add a
> > > > > > >>>>> filter rule and I guess all other devices may enable it in a similar
> > way.
> > > > > > >>>>>> so naturally it should be a device (port) level
> > > > > > >>>>>> configuration but not a rte_flow
> > > > > > >>>>> rule for match, encap, decap...
> > > > > > >>>>>
> > > > > > >>>>> I don't understand how it helps to identify an UDP port if
> > > > > > >>>>> there is no rule for this tunnel.
> > > > > > >>>>> What is the usage?
> > > > > > >>>>
> > > > > > >>>> Yes, in general It is a rule, it matches a udp packet's dst
> > > > > > >>>> port and the action is
> > > > > > >>> "now the packet is identified as vxlan packet" then all
> > > > > > >>> other rte_flow rules that match for a vlxan as pattern will take
> > effect.
> > > > > > >>> but somehow, I think they are not rules in the same domain,
> > > > > > >>> just like we have dedicate API for mac/vlan filter, we'd
> > > > > > >>> better have a dedicate API for this also. ( RFC for Vxlan
> > > > > > >>> explains why we need this.
> > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fto
> > > > ols.ietf
> > > > .org%2Fhtml%2Frfc7348&amp;data=04%7C01%7Corika%40nvidia.com%7C
> > 46b2
> > > >
> > d8f48944422f0d9008d8b43a2293%7C43083d15727340c1b7db39efd9ccc17a
> > %7
> > > >
> > C0%7C0%7C637457509081543237%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> > MC
> > > >
> > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&a
> > > >
> > mp;sdata=RYWFMjuxkcUZ982kK2s44tBAjf%2FTkDyaa7VEybCtxOo%3D&amp;r
> > es
> > > > erved=0).
> > > > > > >>>>
> > > > > > >>>> "Destination Port: IANA has assigned the value 4789 for the
> > > > > > >>>> VXLAN UDP port, and this value SHOULD be used by default as
> > > > > > >>>> the destination UDP port.  Some early implementations of
> > > > > > >>>> VXLAN have used other values for the destination port.  To
> > > > > > >>>> enable interoperability with these implementations, the
> > > > > > >>>> destination port
> > > > > SHOULD be configurable."
> > > > > > >>>
> > > > > > >>> Yes the port number is free.
> > > > > > >>> But isn't it more natural to specify this port number as
> > > > > > >>> part of the rte_flow rule?
> > > > > > >>
> > > > > > >> I think if we have a rte_flow action type that can be used to
> > > > > > >> set a packet's tunnel type xxx, like below #flow create
> > > > > > >> eth/ipv4/udp port is 4789/... action set_tunnel_type VxLAN /
> > > > > > >> end then we may replace it with rte_flow, but I'm not sure if
> > > > > > >> it's necessary, please share if you have a better idea.
> > > > >
> > > > > Of course we can specify the UDP port in rte_flow rule.
> > > > > Please check rte_flow_item_udp.
> > > > > That's a basic of rte_flow.
> > > >
> > > > Its not about the pattern match, it's about the action, what we need
> > > > is a rte_flow action to "define a packet's tunnel type", but we don't have.
> > 
> > A packet type alone is meaningless.
> > It is always associated to an action, this is what rte_flow does.
> 
> As I mentioned in previous, this is a device (port) level configuration, so it can only be configured by a PF driver or a privileged VF base on our security model.
> A typical usage in a NFV environment could be:
> 
> 1. A privileged VF (e.g. ice_dcf PMD) use rte_eth_dev_udp_tunnel_port_add to create tunnel port for eCPRI, them this will impact on all VFs in the same PF.
> 2. A normal VF driver can create rte_flow rule that match specific patch for queue steering or apply RSS for eCPRI packets, but it DON'T have the permission to define the tunnel port.

Whaooh! A normal Intel VF is not allowed to match the tunnel it wants
if not enabled by a priviledged VF?
I would say it is a HW design flaw, but that's not the question.

> So it does not help to have a rte_flow that match dst udp port
> as tunnel while have an action in the same rule.

Now I understand you are truly looking for a device configuration.
But as it looks more as a HW limitation,
I don't think it should be part of ethdev.
The fact is that it is already part of ethdev...

I don't know what to say. I need to digest how Intel limitation
is "still" trying to drive some parts of the "generic" API.


> > > > #flow create eth/ipv4/udp port is 4789/... action set_tunnel_type
> > > > VxLAN
> > > >
> > > > I think rte_eth_dev_udp_tunnel_port_add does this job well already,
> > > > if we plan to move it to rte_flow, at least we need a replacement solution.
> > 
> > The documentation does not say why it is useful.
> > With rte_flow you don't need it because a flow is specified with its action.
> > 
> > 
> > > Let me see if I understand it correctly.
> > > In your case, the issue is that you need to configure the HW to parse the
> > packet correctly right?
> > > It is not about the matching it is about the configuration of the HW,
> > > you wish to tell the HW that the packet should be parsed by different means
> > correct?
> > >
> > > If this is the case it sounds to me that you should use rte_flow and
> > > if the user adds the following rule:
> > > #flow create pattern eth / ivp4 / udp port is 4789 / .. action .....
> > > You simply need to configure your HW to support the ecpri configuration.
> > >
> > >
> > > > >
> > > > >
> > > > > > > Isn't this more a device configuration than filtering, not
> > > > > > > sure about using rte_flow for this.
> > > > > >
> > > > > > +1
> > > > >
> > > > > A device configuration? No, setting an UDP port is a stack configuration.
> > > > >
> > > > >
> > > > > > >> BTW, are we going to move all other filter like mac , VLAN
> > > > > > >> filter/strip/insert into rte_flow finally?
> > > > >
> > > > > Yes I think it should be the direction.
> > > > > All of this can be achieved with rte_flow.
> > > > >
> > > > >
> > > > > > >> if that's the plan, though I don't have much inputs for this
> > > > > > >> right now, but I think we may not need to prevent new
> > > > > > >> features be added based on current API if it does not
> > > > > > >> introduce more complexity and not break anything.
> > > > >
> > > > > If we continue updating old API, we are just forking ourself:
> > > > > having 2 APIs for the same feature is a non-sense.
> > > > > We must remove APIs which are superseded by rte_flow.

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Zhang, Qi Z]

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Monday, January 11, 2021 7:38 PM
> To: Yigit, Ferruh <ferruh.yigit@intel.com>; Guo, Jia <jia.guo@intel.com>; Zhang,
> Qi Z <qi.z.zhang@intel.com>
> Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>; Ori Kam
> <orika@nvidia.com>; Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
> <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
> dev@dpdk.org; Gregory Etelson <getelson@nvidia.com>;
> maxime.coquelin@redhat.com; jerinj@marvell.com;
> ajit.khaparde@broadcom.com
> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
> 
> 11/01/2021 12:26, Zhang, Qi Z:
> > From: Thomas Monjalon <thomas@monjalon.net>
> > > 10/01/2021 11:46, Ori Kam:
> > > > From: Zhang, Qi Z <qi.z.zhang@intel.com>
> > > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > 08/01/2021 10:29, Andrew Rybchenko:
> > > > > > > On 1/8/21 11:57 AM, Ferruh Yigit wrote:
> > > > > > > > On 1/8/2021 1:41 AM, Zhang, Qi Z wrote:
> > > > > > > >> From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > > >>> 07/01/2021 16:24, Zhang, Qi Z:
> > > > > > > >>>> From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > > >>>>> 07/01/2021 13:47, Zhang, Qi Z:
> > > > > > > >>>>>> From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > > >>>>>>> 07/01/2021 10:32, Guo, Jia:
> > > > > > > >>>>>>>> From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > > >>>>>>>>> 24/12/2020 07:59, Jeff Guo:
> > > > > > > >>>>>>>>>> --- a/lib/librte_ethdev/rte_ethdev.h
> > > > > > > >>>>>>>>>> +++ b/lib/librte_ethdev/rte_ethdev.h
> > > > > > > >>>>>>>>>> @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
> > > > > > > >>>>>>>>>>       RTE_TUNNEL_TYPE_IP_IN_GRE,
> > > > > > > >>>>>>>>>>       RTE_L2_TUNNEL_TYPE_E_TAG,
> > > > > > > >>>>>>>>>>       RTE_TUNNEL_TYPE_VXLAN_GPE,
> > > > > > > >>>>>>>>>> +    RTE_TUNNEL_TYPE_ECPRI,
> > > > > > > >>>>>>>>>>       RTE_TUNNEL_TYPE_MAX,
> > > > > > > >>>>>>>>>>   };
> > > > > > > >>>>>>>>>
> > > > > > > >>>>>>>>> We tried to remove all these legacy API in DPDK 20.11.
> > > > > > > >>>>>>>>> Andrew decided to not remove this one because it
> > > > > > > >>>>>>>>> is not yet completely replaced by rte_flow in all drivers.
> > > > > > > >>>>>>>>> However, I am against continuing to update this API.
> > > > > > > >>>>>>>>> The opposite work should be done: migrate to rte_flow.
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>> Agree but seems that the legacy api and driver
> > > > > > > >>>>>>>> legacy implementation still keep in this release,
> > > > > > > >>>>>>>> and there is no a general way to replace the legacy by
> rte_flow right now.
> > > > > > > >>>>>>>
> > > > > > > >>>>>>> I think rte_flow is a complete replacement with more
> features.
> > > > > > > >>>>>>
> > > > > > > >>>>>> Thomas, I may not agree with this.
> > > > > > > >>>>>>
> > > > > > > >>>>>> Actually the "enum rte_eth_tunnel_type" is used by
> > > > > > > >>>>>> rte_eth_dev_udp_tunnel_port_add A packet with
> > > > > > > >>>>>> specific dst udp port will be recognized as a
> > > > > > > >>>>>> specific tunnel packet type
> > > (e.g.
> > > > > > > >>>>>> vxlan, vxlan-gpe,
> > > > > > > >>>>> ecpri...) In Intel NIC, the API actually changes the
> > > > > > > >>>>> configuration of the packet parser in HW but not add a
> > > > > > > >>>>> filter rule and I guess all other devices may enable
> > > > > > > >>>>> it in a similar
> > > way.
> > > > > > > >>>>>> so naturally it should be a device (port) level
> > > > > > > >>>>>> configuration but not a rte_flow
> > > > > > > >>>>> rule for match, encap, decap...
> > > > > > > >>>>>
> > > > > > > >>>>> I don't understand how it helps to identify an UDP
> > > > > > > >>>>> port if there is no rule for this tunnel.
> > > > > > > >>>>> What is the usage?
> > > > > > > >>>>
> > > > > > > >>>> Yes, in general It is a rule, it matches a udp packet's
> > > > > > > >>>> dst port and the action is
> > > > > > > >>> "now the packet is identified as vxlan packet" then all
> > > > > > > >>> other rte_flow rules that match for a vlxan as pattern
> > > > > > > >>> will take
> > > effect.
> > > > > > > >>> but somehow, I think they are not rules in the same
> > > > > > > >>> domain, just like we have dedicate API for mac/vlan
> > > > > > > >>> filter, we'd better have a dedicate API for this also. (
> > > > > > > >>> RFC for Vxlan explains why we need this.
> > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%
> > > > > 2Fto
> > > > > ols.ietf
> > > > > .org%2Fhtml%2Frfc7348&amp;data=04%7C01%7Corika%40nvidia.com
> %7C
> > > 46b2
> > > > >
> > >
> d8f48944422f0d9008d8b43a2293%7C43083d15727340c1b7db39efd9ccc17a
> > > %7
> > > > >
> > >
> C0%7C0%7C637457509081543237%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> > > MC
> > > > >
> > >
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&a
> > > > >
> > >
> mp;sdata=RYWFMjuxkcUZ982kK2s44tBAjf%2FTkDyaa7VEybCtxOo%3D&amp;r
> > > es
> > > > > erved=0).
> > > > > > > >>>>
> > > > > > > >>>> "Destination Port: IANA has assigned the value 4789 for
> > > > > > > >>>> the VXLAN UDP port, and this value SHOULD be used by
> > > > > > > >>>> default as the destination UDP port.  Some early
> > > > > > > >>>> implementations of VXLAN have used other values for the
> > > > > > > >>>> destination port.  To enable interoperability with
> > > > > > > >>>> these implementations, the destination port
> > > > > > SHOULD be configurable."
> > > > > > > >>>
> > > > > > > >>> Yes the port number is free.
> > > > > > > >>> But isn't it more natural to specify this port number as
> > > > > > > >>> part of the rte_flow rule?
> > > > > > > >>
> > > > > > > >> I think if we have a rte_flow action type that can be
> > > > > > > >> used to set a packet's tunnel type xxx, like below #flow
> > > > > > > >> create eth/ipv4/udp port is 4789/... action
> > > > > > > >> set_tunnel_type VxLAN / end then we may replace it with
> > > > > > > >> rte_flow, but I'm not sure if it's necessary, please share if you have
> a better idea.
> > > > > >
> > > > > > Of course we can specify the UDP port in rte_flow rule.
> > > > > > Please check rte_flow_item_udp.
> > > > > > That's a basic of rte_flow.
> > > > >
> > > > > Its not about the pattern match, it's about the action, what we
> > > > > need is a rte_flow action to "define a packet's tunnel type", but we don't
> have.
> > >
> > > A packet type alone is meaningless.
> > > It is always associated to an action, this is what rte_flow does.
> >
> > As I mentioned in previous, this is a device (port) level configuration, so it can
> only be configured by a PF driver or a privileged VF base on our security model.
> > A typical usage in a NFV environment could be:
> >
> > 1. A privileged VF (e.g. ice_dcf PMD) use rte_eth_dev_udp_tunnel_port_add
> to create tunnel port for eCPRI, them this will impact on all VFs in the same PF.
> > 2. A normal VF driver can create rte_flow rule that match specific patch for
> queue steering or apply RSS for eCPRI packets, but it DON'T have the
> permission to define the tunnel port.
> 
> Whaooh! A normal Intel VF is not allowed to match the tunnel it wants if not
> enabled by a priviledged VF?

> I would say it is a HW design flaw, but that's not the question.	

Why you think this is a design flaw? in real case, is it a typical requirement that different VF need different tunnel port for eCPRI (or VxLan) on the same PF? 
I believe it's not necessary to make it as a per VF resource in most cases, and I will be surprise if a driver that allow any VF to change the share resource without any privilege control.

Btw I guess mlx NIC has more flexible way to handle ecpri tunnel, just curious how it works, what's the expected result of below rules?

1. create flow eth / ipv4 / udp dst is 1234 / ecpri msgtype is 0 / ... to queue 0
2. create flow eth / ipv4 / udp dst is 5678 / ecrpi msgtype is 1 / ... to queue 1.

So both 1234 and 5678 will be regarded as an ECPRI packet? Or only the first one will work?
does dst udp port is always needed if an ecpri pattern is involved?


> 
> > So it does not help to have a rte_flow that match dst udp port as
> > tunnel while have an action in the same rule.
> 
> Now I understand you are truly looking for a device configuration.
> But as it looks more as a HW limitation, I don't think it should be part of ethdev.
> The fact is that it is already part of ethdev...
> 
> I don't know what to say. I need to digest how Intel limitation is "still" trying to
> drive some parts of the "generic" API.
> 
> 
> > > > > #flow create eth/ipv4/udp port is 4789/... action
> > > > > set_tunnel_type VxLAN
> > > > >
> > > > > I think rte_eth_dev_udp_tunnel_port_add does this job well
> > > > > already, if we plan to move it to rte_flow, at least we need a replacement
> solution.
> > >
> > > The documentation does not say why it is useful.
> > > With rte_flow you don't need it because a flow is specified with its action.
> > >
> > >
> > > > Let me see if I understand it correctly.
> > > > In your case, the issue is that you need to configure the HW to
> > > > parse the
> > > packet correctly right?
> > > > It is not about the matching it is about the configuration of the
> > > > HW, you wish to tell the HW that the packet should be parsed by
> > > > different means
> > > correct?
> > > >
> > > > If this is the case it sounds to me that you should use rte_flow
> > > > and if the user adds the following rule:
> > > > #flow create pattern eth / ivp4 / udp port is 4789 / .. action .....
> > > > You simply need to configure your HW to support the ecpri configuration.
> > > >
> > > >
> > > > > >
> > > > > >
> > > > > > > > Isn't this more a device configuration than filtering, not
> > > > > > > > sure about using rte_flow for this.
> > > > > > >
> > > > > > > +1
> > > > > >
> > > > > > A device configuration? No, setting an UDP port is a stack
> configuration.
> > > > > >
> > > > > >
> > > > > > > >> BTW, are we going to move all other filter like mac ,
> > > > > > > >> VLAN filter/strip/insert into rte_flow finally?
> > > > > >
> > > > > > Yes I think it should be the direction.
> > > > > > All of this can be achieved with rte_flow.
> > > > > >
> > > > > >
> > > > > > > >> if that's the plan, though I don't have much inputs for
> > > > > > > >> this right now, but I think we may not need to prevent
> > > > > > > >> new features be added based on current API if it does not
> > > > > > > >> introduce more complexity and not break anything.
> > > > > >
> > > > > > If we continue updating old API, we are just forking ourself:
> > > > > > having 2 APIs for the same feature is a non-sense.
> > > > > > We must remove APIs which are superseded by rte_flow.
> 
> 

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Thomas Monjalon]

11/01/2021 15:02, Zhang, Qi Z:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 11/01/2021 12:26, Zhang, Qi Z:
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > 10/01/2021 11:46, Ori Kam:
> > > > > From: Zhang, Qi Z <qi.z.zhang@intel.com>
> > > > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > > 08/01/2021 10:29, Andrew Rybchenko:
> > > > > > > > On 1/8/21 11:57 AM, Ferruh Yigit wrote:
> > > > > > > > > On 1/8/2021 1:41 AM, Zhang, Qi Z wrote:
> > > > > > > > >> From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > > > >>> Yes the port number is free.
> > > > > > > > >>> But isn't it more natural to specify this port number as
> > > > > > > > >>> part of the rte_flow rule?
> > > > > > > > >>
> > > > > > > > >> I think if we have a rte_flow action type that can be
> > > > > > > > >> used to set a packet's tunnel type xxx, like below #flow
> > > > > > > > >> create eth/ipv4/udp port is 4789/... action
> > > > > > > > >> set_tunnel_type VxLAN / end then we may replace it with
> > > > > > > > >> rte_flow, but I'm not sure if it's necessary,
> > > > > > > > >> please share if you have a better idea.
> > > > > > >
> > > > > > > Of course we can specify the UDP port in rte_flow rule.
> > > > > > > Please check rte_flow_item_udp.
> > > > > > > That's a basic of rte_flow.
> > > > > >
> > > > > > Its not about the pattern match, it's about the action, what we
> > > > > > need is a rte_flow action to "define a packet's tunnel type", but we don't
> > have.
> > > >
> > > > A packet type alone is meaningless.
> > > > It is always associated to an action, this is what rte_flow does.
> > >
> > > As I mentioned in previous, this is a device (port) level configuration, so it can
> > only be configured by a PF driver or a privileged VF base on our security model.
> > > A typical usage in a NFV environment could be:
> > >
> > > 1. A privileged VF (e.g. ice_dcf PMD) use rte_eth_dev_udp_tunnel_port_add
> > to create tunnel port for eCPRI, them this will impact on all VFs in the same PF.
> > > 2. A normal VF driver can create rte_flow rule that match specific patch for
> > queue steering or apply RSS for eCPRI packets, but it DON'T have the
> > permission to define the tunnel port.
> > 
> > Whaooh! A normal Intel VF is not allowed to match the tunnel it wants if not
> > enabled by a priviledged VF?
> 
> > I would say it is a HW design flaw, but that's not the question.	
> 
> Why you think this is a design flaw? in real case,
> is it a typical requirement that different VF
> need different tunnel port for eCPRI (or VxLan) on the same PF?

They are different VFs, so why should they use the same UDP port?
Anyway it doesn't need to be typical to be allowed.

> I believe it's not necessary to make it as a per VF resource
> in most cases, and I will be surprise if a driver that
> allow any VF to change the share resource without any privilege control.

The thing is that a flow rule should not be a shared resource.
In Intel devices, it seems the UDP port of a protocol is supposed
to be shared with all VFs, but it looks a very specific assumption,
or limitation.
I wonder how we can document this and ask the user to call
rte_eth_dev_udp_tunnel_port_add(), because of some devices.
Anyway, this is currently poorly documented.

> Btw I guess mlx NIC has more flexible way to handle ecpri tunnel,
> just curious how it works, what's the expected result of below rules?
> 
> 1. create flow eth / ipv4 / udp dst is 1234 / ecpri msgtype is 0 / ... to queue 0
> 2. create flow eth / ipv4 / udp dst is 5678 / ecrpi msgtype is 1 / ... to queue 1.

It should move the eCPRI packets to the right queue,
taking into consideration the UDP port and the message type.
Of course there may be some bugs :)

> So both 1234 and 5678 will be regarded as an ECPRI packet?

Yes, both should be considered eCPRI.

> Or only the first one will work?

I am not aware of such limitation.

> does dst udp port is always needed if an ecpri pattern is involved?

No, the UDP part is optional.

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Zhang, Qi Z]

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Monday, January 11, 2021 10:54 PM
> To: Yigit, Ferruh <ferruh.yigit@intel.com>; Guo, Jia <jia.guo@intel.com>; Zhang,
> Qi Z <qi.z.zhang@intel.com>
> Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>; Ori Kam
> <orika@nvidia.com>; Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
> <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
> dev@dpdk.org; Gregory Etelson <getelson@nvidia.com>;
> maxime.coquelin@redhat.com; jerinj@marvell.com;
> ajit.khaparde@broadcom.com; Bing Zhao <bingz@nvidia.com>
> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
> 
> 11/01/2021 15:02, Zhang, Qi Z:
> > From: Thomas Monjalon <thomas@monjalon.net>
> > > 11/01/2021 12:26, Zhang, Qi Z:
> > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > 10/01/2021 11:46, Ori Kam:
> > > > > > From: Zhang, Qi Z <qi.z.zhang@intel.com>
> > > > > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > > > 08/01/2021 10:29, Andrew Rybchenko:
> > > > > > > > > On 1/8/21 11:57 AM, Ferruh Yigit wrote:
> > > > > > > > > > On 1/8/2021 1:41 AM, Zhang, Qi Z wrote:
> > > > > > > > > >> From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > > > > >>> Yes the port number is free.
> > > > > > > > > >>> But isn't it more natural to specify this port
> > > > > > > > > >>> number as part of the rte_flow rule?
> > > > > > > > > >>
> > > > > > > > > >> I think if we have a rte_flow action type that can be
> > > > > > > > > >> used to set a packet's tunnel type xxx, like below
> > > > > > > > > >> #flow create eth/ipv4/udp port is 4789/... action
> > > > > > > > > >> set_tunnel_type VxLAN / end then we may replace it
> > > > > > > > > >> with rte_flow, but I'm not sure if it's necessary,
> > > > > > > > > >> please share if you have a better idea.
> > > > > > > >
> > > > > > > > Of course we can specify the UDP port in rte_flow rule.
> > > > > > > > Please check rte_flow_item_udp.
> > > > > > > > That's a basic of rte_flow.
> > > > > > >
> > > > > > > Its not about the pattern match, it's about the action, what
> > > > > > > we need is a rte_flow action to "define a packet's tunnel
> > > > > > > type", but we don't
> > > have.
> > > > >
> > > > > A packet type alone is meaningless.
> > > > > It is always associated to an action, this is what rte_flow does.
> > > >
> > > > As I mentioned in previous, this is a device (port) level
> > > > configuration, so it can
> > > only be configured by a PF driver or a privileged VF base on our security
> model.
> > > > A typical usage in a NFV environment could be:
> > > >
> > > > 1. A privileged VF (e.g. ice_dcf PMD) use
> > > > rte_eth_dev_udp_tunnel_port_add
> > > to create tunnel port for eCPRI, them this will impact on all VFs in the same
> PF.
> > > > 2. A normal VF driver can create rte_flow rule that match specific
> > > > patch for
> > > queue steering or apply RSS for eCPRI packets, but it DON'T have the
> > > permission to define the tunnel port.
> > >
> > > Whaooh! A normal Intel VF is not allowed to match the tunnel it
> > > wants if not enabled by a priviledged VF?
> >
> > > I would say it is a HW design flaw, but that's not the question.
> >
> > Why you think this is a design flaw? in real case, is it a typical
> > requirement that different VF need different tunnel port for eCPRI (or
> > VxLan) on the same PF?
> 
> They are different VFs, so why should they use the same UDP port?
> Anyway it doesn't need to be typical to be allowed.

Yes, of cause, your can support different UDP tunnel port for different VF, but there are lots of alternative ways to isolate VFs, its just not a big deal for most real use case.
The typical requirement is some customer want eCPRI with UDP port A, while another one want UDP port B, and our NIC is good enough to support both cases separately.
There are seldom cases that different eCPRI tunnel port need to be deployed on the same NIC or same port.
so from my view, it's a reasonable design compromise that lose minor software flexibility but get a more simplified firmware and save more hardware resource from unnecessary usage.

> 
> > I believe it's not necessary to make it as a per VF resource in most
> > cases, and I will be surprise if a driver that allow any VF to change
> > the share resource without any privilege control.
> 
> The thing is that a flow rule should not be a shared resource.
> In Intel devices, it seems the UDP port of a protocol is supposed to be shared
> with all VFs, but it looks a very specific assumption, or limitation.
> I wonder how we can document this and ask the user to call
> rte_eth_dev_udp_tunnel_port_add(), because of some devices.
> Anyway, this is currently poorly documented.

OK, let me check the document to see if anything we can improve.

> 
> > Btw I guess mlx NIC has more flexible way to handle ecpri tunnel, just
> > curious how it works, what's the expected result of below rules?
> >
> > 1. create flow eth / ipv4 / udp dst is 1234 / ecpri msgtype is 0 / ...
> > to queue 0 2. create flow eth / ipv4 / udp dst is 5678 / ecrpi msgtype is 1 / ...
> to queue 1.
> 
> It should move the eCPRI packets to the right queue, taking into consideration
> the UDP port and the message type.
> Of course there may be some bugs :)

I guess it is not just some bugs, I saw below note in Mellanox latest MLX5 driver.
"eCPRI over UDP layer is not yet supported right now",  
but this is not the question, I believe your answers are all fit for the VxLan case :)

For VxLAN offload I note below statement from your user manual

*If you configure multiple UDP ports for offload and exceed the total number of ports supported by hardware, then those additional ports will
still function properly, but will not benefit from any of the stateless offloads. 

Looks like you have a port limitation, additional port that above this number will not work with offload like RSS/steering ...,that's fine.
So my understanding the port resource is not just a regular rule in your general flow table.
The questions is how many is the limitation ?  does each VF has its own resource pool? 
If they are shared, how do you manage these ports? 
What if one malicious VF used up all the tunnel ports, does another VF still get chance to create its own?

> 
> > So both 1234 and 5678 will be regarded as an ECPRI packet?
> 
> Yes, both should be considered eCPRI.
> 
> > Or only the first one will work?
> 
> I am not aware of such limitation.
> 
> > does dst udp port is always needed if an ecpri pattern is involved?
> 
> No, the UDP part is optional.
> 

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Thomas Monjalon]

12/01/2021 03:14, Zhang, Qi Z:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 11/01/2021 15:02, Zhang, Qi Z:
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > 11/01/2021 12:26, Zhang, Qi Z:
> > > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > 10/01/2021 11:46, Ori Kam:
> > > > > > > From: Zhang, Qi Z <qi.z.zhang@intel.com>
> > > > > > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > > > > 08/01/2021 10:29, Andrew Rybchenko:
> > > > > > > > > > On 1/8/21 11:57 AM, Ferruh Yigit wrote:
> > > > > > > > > > > On 1/8/2021 1:41 AM, Zhang, Qi Z wrote:
> > > > > > > > > > >> From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > > > > > >>> Yes the port number is free.
> > > > > > > > > > >>> But isn't it more natural to specify this port
> > > > > > > > > > >>> number as part of the rte_flow rule?
> > > > > > > > > > >>
> > > > > > > > > > >> I think if we have a rte_flow action type that can be
> > > > > > > > > > >> used to set a packet's tunnel type xxx, like below
> > > > > > > > > > >> #flow create eth/ipv4/udp port is 4789/... action
> > > > > > > > > > >> set_tunnel_type VxLAN / end then we may replace it
> > > > > > > > > > >> with rte_flow, but I'm not sure if it's necessary,
> > > > > > > > > > >> please share if you have a better idea.
> > > > > > > > >
> > > > > > > > > Of course we can specify the UDP port in rte_flow rule.
> > > > > > > > > Please check rte_flow_item_udp.
> > > > > > > > > That's a basic of rte_flow.
> > > > > > > >
> > > > > > > > Its not about the pattern match, it's about the action, what
> > > > > > > > we need is a rte_flow action to "define a packet's tunnel
> > > > > > > > type", but we don't
> > > > have.
> > > > > >
> > > > > > A packet type alone is meaningless.
> > > > > > It is always associated to an action, this is what rte_flow does.
> > > > >
> > > > > As I mentioned in previous, this is a device (port) level
> > > > > configuration, so it can
> > > > only be configured by a PF driver or a privileged VF base on our security
> > model.
> > > > > A typical usage in a NFV environment could be:
> > > > >
> > > > > 1. A privileged VF (e.g. ice_dcf PMD) use
> > > > > rte_eth_dev_udp_tunnel_port_add
> > > > to create tunnel port for eCPRI, them this will impact on all VFs in the same
> > PF.
> > > > > 2. A normal VF driver can create rte_flow rule that match specific
> > > > > patch for
> > > > queue steering or apply RSS for eCPRI packets, but it DON'T have the
> > > > permission to define the tunnel port.
> > > >
> > > > Whaooh! A normal Intel VF is not allowed to match the tunnel it
> > > > wants if not enabled by a priviledged VF?
> > >
> > > > I would say it is a HW design flaw, but that's not the question.
> > >
> > > Why you think this is a design flaw? in real case, is it a typical
> > > requirement that different VF need different tunnel port for eCPRI (or
> > > VxLan) on the same PF?
> > 
> > They are different VFs, so why should they use the same UDP port?
> > Anyway it doesn't need to be typical to be allowed.
> 
> Yes, of cause, your can support different UDP tunnel port for different VF, but there are lots of alternative ways to isolate VFs, its just not a big deal for most real use case.
> The typical requirement is some customer want eCPRI with UDP port A, while another one want UDP port B, and our NIC is good enough to support both cases separately.
> There are seldom cases that different eCPRI tunnel port need to be deployed on the same NIC or same port.
> so from my view, it's a reasonable design compromise that lose minor software flexibility but get a more simplified firmware and save more hardware resource from unnecessary usage.
> 
> > 
> > > I believe it's not necessary to make it as a per VF resource in most
> > > cases, and I will be surprise if a driver that allow any VF to change
> > > the share resource without any privilege control.
> > 
> > The thing is that a flow rule should not be a shared resource.
> > In Intel devices, it seems the UDP port of a protocol is supposed to be shared
> > with all VFs, but it looks a very specific assumption, or limitation.
> > I wonder how we can document this and ask the user to call
> > rte_eth_dev_udp_tunnel_port_add(), because of some devices.
> > Anyway, this is currently poorly documented.
> 
> OK, let me check the document to see if anything we can improve.

Thank you for trying to improve the doc.


> > > Btw I guess mlx NIC has more flexible way to handle ecpri tunnel, just
> > > curious how it works, what's the expected result of below rules?
> > >
> > > 1. create flow eth / ipv4 / udp dst is 1234 / ecpri msgtype is 0 / ...
> > > to queue 0 2. create flow eth / ipv4 / udp dst is 5678 / ecrpi msgtype is 1 / ...
> > to queue 1.
> > 
> > It should move the eCPRI packets to the right queue, taking into consideration
> > the UDP port and the message type.
> > Of course there may be some bugs :)
> 
> I guess it is not just some bugs, I saw below note in Mellanox latest MLX5 driver.
> "eCPRI over UDP layer is not yet supported right now",  
> but this is not the question, I believe your answers are all fit for the VxLan case :)
> 
> For VxLAN offload I note below statement from your user manual
> 
> *If you configure multiple UDP ports for offload and exceed the total number of ports supported by hardware, then those additional ports will
> still function properly, but will not benefit from any of the stateless offloads. 
> 
> Looks like you have a port limitation, additional port that above this number will not work with offload like RSS/steering ...,that's fine.
> So my understanding the port resource is not just a regular rule in your general flow table.
> The questions is how many is the limitation ?  does each VF has its own resource pool? 
> If they are shared, how do you manage these ports? 
> What if one malicious VF used up all the tunnel ports, does another VF still get chance to create its own?

Sorry I don't know exactly what are the limitations.
From DPDK point of view, when a flow rule cannot be created,
it returns an error and the app must handle.
Yes the app must handle limitations because there is no magic
with hardware offloads: hardware are all more or less limited,
that's a sad truth of our finite world ;)

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Ferruh Yigit]

On 1/7/2021 1:33 PM, Thomas Monjalon wrote:
> 07/01/2021 13:47, Zhang, Qi Z:
>>
>>> -----Original Message-----
>>> From: Thomas Monjalon <thomas@monjalon.net>
>>> Sent: Thursday, January 7, 2021 6:12 PM
>>> To: Guo, Jia <jia.guo@intel.com>
>>> Cc: Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>;
>>> Yang, Qiming <qiming.yang@intel.com>; Wang, Haiyue
>>> <haiyue.wang@intel.com>; dev@dpdk.org; Yigit, Ferruh
>>> <ferruh.yigit@intel.com>; andrew.rybchenko@oktetlabs.ru; orika@nvidia.com;
>>> getelson@nvidia.com
>>> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
>>>
>>> 07/01/2021 10:32, Guo, Jia:
>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>>> 24/12/2020 07:59, Jeff Guo:
>>>>>> Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunnel
>>>>> type.
>>>>>>
>>>>>> Signed-off-by: Jeff Guo <jia.guo@intel.com>
>>>>>> Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
>>>>> [...]
>>>>>> --- a/lib/librte_ethdev/rte_ethdev.h
>>>>>> +++ b/lib/librte_ethdev/rte_ethdev.h
>>>>>> @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
>>>>>>   	RTE_TUNNEL_TYPE_IP_IN_GRE,
>>>>>>   	RTE_L2_TUNNEL_TYPE_E_TAG,
>>>>>>   	RTE_TUNNEL_TYPE_VXLAN_GPE,
>>>>>> +	RTE_TUNNEL_TYPE_ECPRI,
>>>>>>   	RTE_TUNNEL_TYPE_MAX,
>>>>>>   };
>>>>>
>>>>> We tried to remove all these legacy API in DPDK 20.11.
>>>>> Andrew decided to not remove this one because it is not yet
>>>>> completely replaced by rte_flow in all drivers.
>>>>> However, I am against continuing to update this API.
>>>>> The opposite work should be done: migrate to rte_flow.
>>>>
>>>> Agree but seems that the legacy api and driver legacy implementation
>>>> still keep in this release, and there is no a general way to replace
>>>> the legacy by rte_flow right now.
>>>
>>> I think rte_flow is a complete replacement with more features.
>>
>> Thomas, I may not agree with this.
>>
>> Actually the "enum rte_eth_tunnel_type" is used by rte_eth_dev_udp_tunnel_port_add
>> A packet with specific dst udp port will be recognized as a specific tunnel packet type (e.g. vxlan, vxlan-gpe, ecpri...)
>> In Intel NIC, the API actually changes the configuration of the packet parser in HW but not add a filter rule and I guess all other devices may enable it in a similar way.
>> so naturally it should be a device (port) level configuration but not a rte_flow rule for match, encap, decap...
> 
> I don't understand how it helps to identify an UDP port
> if there is no rule for this tunnel.
> What is the usage?
> 
>> So I think it's not a good idea to replace
>> the rte_eth_dev_udp_tunnel_port_add with rte_flow config
>> and also there is no existing rte_flow_action
>> can cover this requirement unless we introduce some new one.
>>
>>> You can match, encap, decap.
>>> There is even a new API to get tunnel infos after decap.
>>> What is missing?
> 
> I still don't see which use case is missing.
> 
> 
>>>>> Sorry, it is a nack.
>>>>> BTW, it is probably breaking the ABI because of RTE_TUNNEL_TYPE_MAX.
>>
>> Yes that may break the ABI but fortunately the checking-abi-compatibility tool shows negative :) , thanks Ferruh' s guide.
>> https://github.com/ferruhy/dpdk/actions/runs/468859673
> 
> That's very strange. An enum value is changed.
> Why it is not flagged by libabigail?
> 

As long as the enum values not sent to the application and kept within the 
library, changing their values shouldn't be problem.

> 
>>>> Oh, the ABI break should be a problem.
>>>>
>>>>> PS: please Cc ethdev maintainers for such patch, thanks.
>>>>> tip: use --cc-cmd devtools/get-maintainer.sh
>>>>
>>>> Thanks for your helpful tip.
> 
> 
> 

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Thomas Monjalon]

08/01/2021 10:22, Ferruh Yigit:
> On 1/7/2021 1:33 PM, Thomas Monjalon wrote:
> > 07/01/2021 13:47, Zhang, Qi Z:
> >> From: Thomas Monjalon <thomas@monjalon.net>
> >>> 07/01/2021 10:32, Guo, Jia:
> >>>> From: Thomas Monjalon <thomas@monjalon.net>
> >>>>> Sorry, it is a nack.
> >>>>> BTW, it is probably breaking the ABI because of RTE_TUNNEL_TYPE_MAX.
> >>
> >> Yes that may break the ABI but fortunately the checking-abi-compatibility tool shows negative :) , thanks Ferruh' s guide.
> >> https://github.com/ferruhy/dpdk/actions/runs/468859673
> > 
> > That's very strange. An enum value is changed.
> > Why it is not flagged by libabigail?
> 
> As long as the enum values not sent to the application and kept within the 
> library, changing their values shouldn't be problem.

But RTE_TUNNEL_TYPE_MAX is part of lib/librte_ethdev/rte_ethdev.h
so it is exposed to the application.
I think it is a case of ABI breakage.

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Ferruh Yigit]

On 1/8/2021 10:23 AM, Thomas Monjalon wrote:
> 08/01/2021 10:22, Ferruh Yigit:
>> On 1/7/2021 1:33 PM, Thomas Monjalon wrote:
>>> 07/01/2021 13:47, Zhang, Qi Z:
>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>>> 07/01/2021 10:32, Guo, Jia:
>>>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>>>>> Sorry, it is a nack.
>>>>>>> BTW, it is probably breaking the ABI because of RTE_TUNNEL_TYPE_MAX.
>>>>
>>>> Yes that may break the ABI but fortunately the checking-abi-compatibility tool shows negative :) , thanks Ferruh' s guide.
>>>> https://github.com/ferruhy/dpdk/actions/runs/468859673
>>>
>>> That's very strange. An enum value is changed.
>>> Why it is not flagged by libabigail?
>>
>> As long as the enum values not sent to the application and kept within the
>> library, changing their values shouldn't be problem.
> 
> But RTE_TUNNEL_TYPE_MAX is part of lib/librte_ethdev/rte_ethdev.h
> so it is exposed to the application.
> I think it is a case of ABI breakage.
> 

Yes it is exposed to the application. But in runtime does it exchanged between 
library and application is the issue I think.
For this case it seems it is not, so not an ABI break.

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Thomas Monjalon]

08/01/2021 11:43, Ferruh Yigit:
> On 1/8/2021 10:23 AM, Thomas Monjalon wrote:
> > 08/01/2021 10:22, Ferruh Yigit:
> >> On 1/7/2021 1:33 PM, Thomas Monjalon wrote:
> >>> 07/01/2021 13:47, Zhang, Qi Z:
> >>>> From: Thomas Monjalon <thomas@monjalon.net>
> >>>>> 07/01/2021 10:32, Guo, Jia:
> >>>>>> From: Thomas Monjalon <thomas@monjalon.net>
> >>>>>>> Sorry, it is a nack.
> >>>>>>> BTW, it is probably breaking the ABI because of RTE_TUNNEL_TYPE_MAX.
> >>>>
> >>>> Yes that may break the ABI but fortunately the checking-abi-compatibility tool shows negative :) , thanks Ferruh' s guide.
> >>>> https://github.com/ferruhy/dpdk/actions/runs/468859673
> >>>
> >>> That's very strange. An enum value is changed.
> >>> Why it is not flagged by libabigail?
> >>
> >> As long as the enum values not sent to the application and kept within the
> >> library, changing their values shouldn't be problem.
> > 
> > But RTE_TUNNEL_TYPE_MAX is part of lib/librte_ethdev/rte_ethdev.h
> > so it is exposed to the application.
> > I think it is a case of ABI breakage.
> 
> Yes it is exposed to the application. But in runtime does it exchanged between 
> library and application is the issue I think.
> For this case it seems it is not, so not an ABI break.

If I create a table of size RTE_TUNNEL_TYPE_MAX with DPDK 20.11,
I will get an overflow when writing to the new ECPRI index.
The question is: can I receive the ECPRI value dynamically from ethdev?
If yes, it is an ABI breakage. But I cannot think of such case now.

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Kinsella, Ray]

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Friday 8 January 2021 14:06
> To: Guo, Jia <jia.guo@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>;
> Yigit, Ferruh <ferruh.yigit@intel.com>
> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
> <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
> dev@dpdk.org; andrew.rybchenko@oktetlabs.ru; orika@nvidia.com;
> getelson@nvidia.com; Dodji Seketeli <dodji@redhat.com>; Kinsella, Ray
> <ray.kinsella@intel.com>
> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type
> for ecpri
> 
> 08/01/2021 11:43, Ferruh Yigit:
> > On 1/8/2021 10:23 AM, Thomas Monjalon wrote:
> > > 08/01/2021 10:22, Ferruh Yigit:
> > >> On 1/7/2021 1:33 PM, Thomas Monjalon wrote:
> > >>> 07/01/2021 13:47, Zhang, Qi Z:
> > >>>> From: Thomas Monjalon <thomas@monjalon.net>
> > >>>>> 07/01/2021 10:32, Guo, Jia:
> > >>>>>> From: Thomas Monjalon <thomas@monjalon.net>
> > >>>>>>> Sorry, it is a nack.
> > >>>>>>> BTW, it is probably breaking the ABI because of
> RTE_TUNNEL_TYPE_MAX.
> > >>>>
> > >>>> Yes that may break the ABI but fortunately the checking-abi-
> compatibility tool shows negative :) , thanks Ferruh' s guide.
> > >>>> https://github.com/ferruhy/dpdk/actions/runs/468859673
> > >>>
> > >>> That's very strange. An enum value is changed.
> > >>> Why it is not flagged by libabigail?
> > >>
> > >> As long as the enum values not sent to the application and kept
> > >> within the library, changing their values shouldn't be problem.
> > >
> > > But RTE_TUNNEL_TYPE_MAX is part of lib/librte_ethdev/rte_ethdev.h
> so
> > > it is exposed to the application.
> > > I think it is a case of ABI breakage.
> >
> > Yes it is exposed to the application. But in runtime does it
> exchanged
> > between library and application is the issue I think.
> > For this case it seems it is not, so not an ABI break.
> 
> If I create a table of size RTE_TUNNEL_TYPE_MAX with DPDK 20.11, I will
> get an overflow when writing to the new ECPRI index.

I guess the question is - are you likely to do this?

> The question is: can I receive the ECPRI value dynamically from ethdev?
> If yes, it is an ABI breakage. But I cannot think of such case now.

Ray K

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Thomas Monjalon]

08/01/2021 15:07, Kinsella, Ray:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 08/01/2021 11:43, Ferruh Yigit:
> > > On 1/8/2021 10:23 AM, Thomas Monjalon wrote:
> > > > 08/01/2021 10:22, Ferruh Yigit:
> > > >> On 1/7/2021 1:33 PM, Thomas Monjalon wrote:
> > > >>> 07/01/2021 13:47, Zhang, Qi Z:
> > > >>>> From: Thomas Monjalon <thomas@monjalon.net>
> > > >>>>> 07/01/2021 10:32, Guo, Jia:
> > > >>>>>> From: Thomas Monjalon <thomas@monjalon.net>
> > > >>>>>>> Sorry, it is a nack.
> > > >>>>>>> BTW, it is probably breaking the ABI because of
> > RTE_TUNNEL_TYPE_MAX.
> > > >>>>
> > > >>>> Yes that may break the ABI but fortunately the checking-abi-
> > compatibility tool shows negative :) , thanks Ferruh' s guide.
> > > >>>> https://github.com/ferruhy/dpdk/actions/runs/468859673
> > > >>>
> > > >>> That's very strange. An enum value is changed.
> > > >>> Why it is not flagged by libabigail?
> > > >>
> > > >> As long as the enum values not sent to the application and kept
> > > >> within the library, changing their values shouldn't be problem.
> > > >
> > > > But RTE_TUNNEL_TYPE_MAX is part of lib/librte_ethdev/rte_ethdev.h
> > so
> > > > it is exposed to the application.
> > > > I think it is a case of ABI breakage.
> > >
> > > Yes it is exposed to the application. But in runtime does it
> > exchanged
> > > between library and application is the issue I think.
> > > For this case it seems it is not, so not an ABI break.
> > 
> > If I create a table of size RTE_TUNNEL_TYPE_MAX with DPDK 20.11, I will
> > get an overflow when writing to the new ECPRI index.
> 
> I guess the question is - are you likely to do this?

As said below, no I cannot think about such a case myself.

> > The question is: can I receive the ECPRI value dynamically from ethdev?
> > If yes, it is an ABI breakage. But I cannot think of such case now.

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Kinsella, Ray]

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Friday 8 January 2021 10:24
> To: Guo, Jia <jia.guo@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>;
> Yigit, Ferruh <ferruh.yigit@intel.com>
> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
> <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
> dev@dpdk.org; andrew.rybchenko@oktetlabs.ru; orika@nvidia.com;
> getelson@nvidia.com; Dodji Seketeli <dodji@redhat.com>; Kinsella, Ray
> <ray.kinsella@intel.com>
> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type
> for ecpri
> 
> 08/01/2021 10:22, Ferruh Yigit:
> > On 1/7/2021 1:33 PM, Thomas Monjalon wrote:
> > > 07/01/2021 13:47, Zhang, Qi Z:
> > >> From: Thomas Monjalon <thomas@monjalon.net>
> > >>> 07/01/2021 10:32, Guo, Jia:
> > >>>> From: Thomas Monjalon <thomas@monjalon.net>
> > >>>>> Sorry, it is a nack.
> > >>>>> BTW, it is probably breaking the ABI because of
> RTE_TUNNEL_TYPE_MAX.
> > >>
> > >> Yes that may break the ABI but fortunately the checking-abi-
> compatibility tool shows negative :) , thanks Ferruh' s guide.
> > >> https://github.com/ferruhy/dpdk/actions/runs/468859673
> > >
> > > That's very strange. An enum value is changed.
> > > Why it is not flagged by libabigail?
> >
> > As long as the enum values not sent to the application and kept
> within
> > the library, changing their values shouldn't be problem.
> 
> But RTE_TUNNEL_TYPE_MAX is part of lib/librte_ethdev/rte_ethdev.h so it
> is exposed to the application.
> I think it is a case of ABI breakage.
> 

Really a lot depends on context, Thomas is right it is hard to predict how these _MAX values are used.

We have seen cases in the past where _MAX enumeration values have been used to size arrays the like - I don't immediately see that issue here. My understanding is that the only consumer of this enumeration is rte_eth_dev_udp_tunnel_port_add and rte_eth_dev_udp_tunnel_port_delete, right? On face value, impact looks negligible. 

I will take a look at why libabigail doesn't complain. 

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Ferruh Yigit]

On 1/8/2021 12:38 PM, Kinsella, Ray wrote:
> 
> 
>> -----Original Message-----
>> From: Thomas Monjalon <thomas@monjalon.net>
>> Sent: Friday 8 January 2021 10:24
>> To: Guo, Jia <jia.guo@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>;
>> Yigit, Ferruh <ferruh.yigit@intel.com>
>> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
>> <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
>> dev@dpdk.org; andrew.rybchenko@oktetlabs.ru; orika@nvidia.com;
>> getelson@nvidia.com; Dodji Seketeli <dodji@redhat.com>; Kinsella, Ray
>> <ray.kinsella@intel.com>
>> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type
>> for ecpri
>>
>> 08/01/2021 10:22, Ferruh Yigit:
>>> On 1/7/2021 1:33 PM, Thomas Monjalon wrote:
>>>> 07/01/2021 13:47, Zhang, Qi Z:
>>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>>>> 07/01/2021 10:32, Guo, Jia:
>>>>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>>>>>> Sorry, it is a nack.
>>>>>>>> BTW, it is probably breaking the ABI because of
>> RTE_TUNNEL_TYPE_MAX.
>>>>>
>>>>> Yes that may break the ABI but fortunately the checking-abi-
>> compatibility tool shows negative :) , thanks Ferruh' s guide.
>>>>> https://github.com/ferruhy/dpdk/actions/runs/468859673
>>>>
>>>> That's very strange. An enum value is changed.
>>>> Why it is not flagged by libabigail?
>>>
>>> As long as the enum values not sent to the application and kept
>> within
>>> the library, changing their values shouldn't be problem.
>>
>> But RTE_TUNNEL_TYPE_MAX is part of lib/librte_ethdev/rte_ethdev.h so it
>> is exposed to the application.
>> I think it is a case of ABI breakage.
>>
> 
> Really a lot depends on context, Thomas is right it is hard to predict how these _MAX values are used.
> 
> We have seen cases in the past where _MAX enumeration values have been used to size arrays the like - I don't immediately see that issue here. My understanding is that the only consumer of this enumeration is rte_eth_dev_udp_tunnel_port_add and rte_eth_dev_udp_tunnel_port_delete, right? On face value, impact looks negligible.
> 
> I will take a look at why libabigail doesn't complain.
> 

Application can use the enum, including MAX as they desire, we can't really 
assume anything there.

In previous case, library was providing an enum value back to application. And 
the problem was application can use those values blindly and new unexpected 
values may cause trouble.

For this case, even the application create a table with RTE_TUNNEL_TYPE_MAX 
size, library is not sending any type of this enum to application to cause any 
problem, at least abigail seems not able to finding any instance of it.

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Kinsella, Ray]

> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Friday 8 January 2021 14:27
> To: Kinsella, Ray <ray.kinsella@intel.com>; Thomas Monjalon
> <thomas@monjalon.net>; Guo, Jia <jia.guo@intel.com>; Zhang, Qi Z
> <qi.z.zhang@intel.com>
> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
> <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
> dev@dpdk.org; andrew.rybchenko@oktetlabs.ru; orika@nvidia.com;
> getelson@nvidia.com; Dodji Seketeli <dodji@redhat.com>
> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type
> for ecpri
> 
> On 1/8/2021 12:38 PM, Kinsella, Ray wrote:
> >
> >
> >> -----Original Message-----
> >> From: Thomas Monjalon <thomas@monjalon.net>
> >> Sent: Friday 8 January 2021 10:24
> >> To: Guo, Jia <jia.guo@intel.com>; Zhang, Qi Z
> <qi.z.zhang@intel.com>;
> >> Yigit, Ferruh <ferruh.yigit@intel.com>
> >> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
> >> <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
> >> dev@dpdk.org; andrew.rybchenko@oktetlabs.ru; orika@nvidia.com;
> >> getelson@nvidia.com; Dodji Seketeli <dodji@redhat.com>; Kinsella,
> Ray
> >> <ray.kinsella@intel.com>
> >> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel
> type
> >> for ecpri
> >>
> >> 08/01/2021 10:22, Ferruh Yigit:
> >>> On 1/7/2021 1:33 PM, Thomas Monjalon wrote:
> >>>> 07/01/2021 13:47, Zhang, Qi Z:
> >>>>> From: Thomas Monjalon <thomas@monjalon.net>
> >>>>>> 07/01/2021 10:32, Guo, Jia:
> >>>>>>> From: Thomas Monjalon <thomas@monjalon.net>
> >>>>>>>> Sorry, it is a nack.
> >>>>>>>> BTW, it is probably breaking the ABI because of
> >> RTE_TUNNEL_TYPE_MAX.
> >>>>>
> >>>>> Yes that may break the ABI but fortunately the checking-abi-
> >> compatibility tool shows negative :) , thanks Ferruh' s guide.
> >>>>> https://github.com/ferruhy/dpdk/actions/runs/468859673
> >>>>
> >>>> That's very strange. An enum value is changed.
> >>>> Why it is not flagged by libabigail?
> >>>
> >>> As long as the enum values not sent to the application and kept
> >> within
> >>> the library, changing their values shouldn't be problem.
> >>
> >> But RTE_TUNNEL_TYPE_MAX is part of lib/librte_ethdev/rte_ethdev.h so
> >> it is exposed to the application.
> >> I think it is a case of ABI breakage.
> >>
> >
> > Really a lot depends on context, Thomas is right it is hard to
> predict how these _MAX values are used.
> >
> > We have seen cases in the past where _MAX enumeration values have
> been used to size arrays the like - I don't immediately see that issue
> here. My understanding is that the only consumer of this enumeration is
> rte_eth_dev_udp_tunnel_port_add and rte_eth_dev_udp_tunnel_port_delete,
> right? On face value, impact looks negligible.
> >
> > I will take a look at why libabigail doesn't complain.
> >
> 
> Application can use the enum, including MAX as they desire, we can't
> really assume anything there.
> 
> In previous case, library was providing an enum value back to
> application. And the problem was application can use those values
> blindly and new unexpected values may cause trouble.
> 
> For this case, even the application create a table with
> RTE_TUNNEL_TYPE_MAX size, library is not sending any type of this enum
> to application to cause any problem, at least abigail seems not able to
> finding any instance of it.

Yes - it makes any problem associated with unlikely then.

Ray K

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Kinsella, Ray]

> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Friday 8 January 2021 14:27
> To: Kinsella, Ray <ray.kinsella@intel.com>; Thomas Monjalon
> <thomas@monjalon.net>; Guo, Jia <jia.guo@intel.com>; Zhang, Qi Z
> <qi.z.zhang@intel.com>
> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
> <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
> dev@dpdk.org; andrew.rybchenko@oktetlabs.ru; orika@nvidia.com;
> getelson@nvidia.com; Dodji Seketeli <dodji@redhat.com>
> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type
> for ecpri
> 
> On 1/8/2021 12:38 PM, Kinsella, Ray wrote:
> >
> >
> >> -----Original Message-----
> >> From: Thomas Monjalon <thomas@monjalon.net>
> >> Sent: Friday 8 January 2021 10:24
> >> To: Guo, Jia <jia.guo@intel.com>; Zhang, Qi Z
> <qi.z.zhang@intel.com>;
> >> Yigit, Ferruh <ferruh.yigit@intel.com>
> >> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
> >> <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
> >> dev@dpdk.org; andrew.rybchenko@oktetlabs.ru; orika@nvidia.com;
> >> getelson@nvidia.com; Dodji Seketeli <dodji@redhat.com>; Kinsella,
> Ray
> >> <ray.kinsella@intel.com>
> >> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel
> type
> >> for ecpri
> >>
> >> 08/01/2021 10:22, Ferruh Yigit:
> >>> On 1/7/2021 1:33 PM, Thomas Monjalon wrote:
> >>>> 07/01/2021 13:47, Zhang, Qi Z:
> >>>>> From: Thomas Monjalon <thomas@monjalon.net>
> >>>>>> 07/01/2021 10:32, Guo, Jia:
> >>>>>>> From: Thomas Monjalon <thomas@monjalon.net>
> >>>>>>>> Sorry, it is a nack.
> >>>>>>>> BTW, it is probably breaking the ABI because of
> >> RTE_TUNNEL_TYPE_MAX.
> >>>>>
> >>>>> Yes that may break the ABI but fortunately the checking-abi-
> >> compatibility tool shows negative :) , thanks Ferruh' s guide.
> >>>>> https://github.com/ferruhy/dpdk/actions/runs/468859673
> >>>>
> >>>> That's very strange. An enum value is changed.
> >>>> Why it is not flagged by libabigail?
> >>>
> >>> As long as the enum values not sent to the application and kept
> >> within
> >>> the library, changing their values shouldn't be problem.
> >>
> >> But RTE_TUNNEL_TYPE_MAX is part of lib/librte_ethdev/rte_ethdev.h so
> >> it is exposed to the application.
> >> I think it is a case of ABI breakage.
> >>
> >
> > Really a lot depends on context, Thomas is right it is hard to
> predict how these _MAX values are used.
> >
> > We have seen cases in the past where _MAX enumeration values have
> been used to size arrays the like - I don't immediately see that issue
> here. My understanding is that the only consumer of this enumeration is
> rte_eth_dev_udp_tunnel_port_add and rte_eth_dev_udp_tunnel_port_delete,
> right? On face value, impact looks negligible.
> >
> > I will take a look at why libabigail doesn't complain.

So I spent some time looking a bit closer at why libabigail didn't complain,
I am summarizing it is because there is no symbol that obviously uses enum rte_eth_tunnel_type.
The prot_type field in rte_eth_udp_tunnel is declared as a uint8_t, not as enum rte_eth_tunnel_type.

Is there a particular reason an enumerated field would be declared as unsigned int instead?

/**
 * UDP tunneling configuration.
 * Used to config the UDP port for a type of tunnel.
 * NICs need the UDP port to identify the tunnel type.
 * Normally a type of tunnel has a default UDP port, this structure can be used
 * in case if the users want to change or support more UDP port.
 */
struct rte_eth_udp_tunnel {
        uint16_t udp_port; /**< UDP port used for the tunnel. */
        uint8_t prot_type; /**< Tunnel type. Defined in rte_eth_tunnel_type. */
};

> 
> Application can use the enum, including MAX as they desire, we can't
> really assume anything there.
> 
> In previous case, library was providing an enum value back to
> application. And the problem was application can use those values
> blindly and new unexpected values may cause trouble.
> 
> For this case, even the application create a table with
> RTE_TUNNEL_TYPE_MAX size, library is not sending any type of this enum
> to application to cause any problem, at least abigail seems not able to
> finding any instance of it.

I agree - I think this has marginal risk. 

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Ferruh Yigit]

On 12/24/2020 6:59 AM, Jeff Guo wrote:
> Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunnel type.
> 
> Signed-off-by: Jeff Guo <jia.guo@intel.com>
> Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>

Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>

But since you will be sending a new version of the set, can you please include a 
short release notes update?

Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri

[Guo, Jia]

> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Thursday, January 14, 2021 10:35 PM
> To: Guo, Jia <jia.guo@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>; Wu,
> Jingjing <jingjing.wu@intel.com>; Yang, Qiming <qiming.yang@intel.com>;
> Wang, Haiyue <haiyue.wang@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for
> ecpri
> 
> On 12/24/2020 6:59 AM, Jeff Guo wrote:
> > Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunnel
> type.
> >
> > Signed-off-by: Jeff Guo <jia.guo@intel.com>
> > Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
> 
> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
> 
> But since you will be sending a new version of the set, can you please include
> a short release notes update?

Sure, please check v3 again, thanks.

[dpdk-dev] [dpdk-dev v2 2/2] app/testpmd: add new UDP tunnel port for ecpri

[Jeff Guo]

Add new UDP tunnel port params for ecpri configuration, the command
as below:

testpmd> port config 0 udp_tunnel_port add ecpri 6789
testpmd> port config 0 udp_tunnel_port rm ecpri 6789

Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
 app/test-pmd/cmdline.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 2ccbaa039e..af08e48e2e 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -9175,6 +9175,8 @@ cmd_cfg_tunnel_udp_port_parsed(void *parsed_result,
 		tunnel_udp.prot_type = RTE_TUNNEL_TYPE_GENEVE;
 	} else if (!strcmp(res->tunnel_type, "vxlan-gpe")) {
 		tunnel_udp.prot_type = RTE_TUNNEL_TYPE_VXLAN_GPE;
+	} else if (!strcmp(res->tunnel_type, "ecpri")) {
+		tunnel_udp.prot_type = RTE_TUNNEL_TYPE_ECPRI;
 	} else {
 		printf("Invalid tunnel type\n");
 		return;
@@ -9209,7 +9211,7 @@ cmdline_parse_token_string_t cmd_config_tunnel_udp_port_action =
 				 "add#rm");
 cmdline_parse_token_string_t cmd_config_tunnel_udp_port_tunnel_type =
 	TOKEN_STRING_INITIALIZER(struct cmd_config_tunnel_udp_port, tunnel_type,
-				 "vxlan#geneve#vxlan-gpe");
+				 "vxlan#geneve#vxlan-gpe#ecpri");
 cmdline_parse_token_num_t cmd_config_tunnel_udp_port_value =
 	TOKEN_NUM_INITIALIZER(struct cmd_config_tunnel_udp_port, udp_port,
 			      RTE_UINT16);
@@ -9217,7 +9219,8 @@ cmdline_parse_token_num_t cmd_config_tunnel_udp_port_value =
 cmdline_parse_inst_t cmd_cfg_tunnel_udp_port = {
 	.f = cmd_cfg_tunnel_udp_port_parsed,
 	.data = NULL,
-	.help_str = "port config <port_id> udp_tunnel_port add|rm vxlan|geneve|vxlan-gpe <udp_port>",
+	.help_str = "port config <port_id> udp_tunnel_port add|rm vxlan|"
+		"geneve|vxlan-gpe|ecpri <udp_port>",
 	.tokens = {
 		(void *)&cmd_config_tunnel_udp_port_port,
 		(void *)&cmd_config_tunnel_udp_port_config,
-- 
2.20.1

Re: [dpdk-dev] [dpdk-dev v2 2/2] app/testpmd: add new UDP tunnel port for ecpri

[Ferruh Yigit]

On 12/24/2020 6:59 AM, Jeff Guo wrote:
> Add new UDP tunnel port params for ecpri configuration, the command
> as below:
> 
> testpmd> port config 0 udp_tunnel_port add ecpri 6789
> testpmd> port config 0 udp_tunnel_port rm ecpri 6789
> 
> Signed-off-by: Jeff Guo <jia.guo@intel.com>
> ---
>   app/test-pmd/cmdline.c | 7 +++++--
>   1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c

Can you please update the 'cmd_help_long_parsed()' for command update,
and update the testpmd documentation, 'testpmd_funcs.rst'?

> index 2ccbaa039e..af08e48e2e 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -9175,6 +9175,8 @@ cmd_cfg_tunnel_udp_port_parsed(void *parsed_result,
>   		tunnel_udp.prot_type = RTE_TUNNEL_TYPE_GENEVE;
>   	} else if (!strcmp(res->tunnel_type, "vxlan-gpe")) {
>   		tunnel_udp.prot_type = RTE_TUNNEL_TYPE_VXLAN_GPE;
> +	} else if (!strcmp(res->tunnel_type, "ecpri")) {
> +		tunnel_udp.prot_type = RTE_TUNNEL_TYPE_ECPRI;
>   	} else {
>   		printf("Invalid tunnel type\n");
>   		return;
> @@ -9209,7 +9211,7 @@ cmdline_parse_token_string_t cmd_config_tunnel_udp_port_action =
>   				 "add#rm");
>   cmdline_parse_token_string_t cmd_config_tunnel_udp_port_tunnel_type =
>   	TOKEN_STRING_INITIALIZER(struct cmd_config_tunnel_udp_port, tunnel_type,
> -				 "vxlan#geneve#vxlan-gpe");
> +				 "vxlan#geneve#vxlan-gpe#ecpri");
>   cmdline_parse_token_num_t cmd_config_tunnel_udp_port_value =
>   	TOKEN_NUM_INITIALIZER(struct cmd_config_tunnel_udp_port, udp_port,
>   			      RTE_UINT16);
> @@ -9217,7 +9219,8 @@ cmdline_parse_token_num_t cmd_config_tunnel_udp_port_value =
>   cmdline_parse_inst_t cmd_cfg_tunnel_udp_port = {
>   	.f = cmd_cfg_tunnel_udp_port_parsed,
>   	.data = NULL,
> -	.help_str = "port config <port_id> udp_tunnel_port add|rm vxlan|geneve|vxlan-gpe <udp_port>",
> +	.help_str = "port config <port_id> udp_tunnel_port add|rm vxlan|"
> +		"geneve|vxlan-gpe|ecpri <udp_port>",
>   	.tokens = {
>   		(void *)&cmd_config_tunnel_udp_port_port,
>   		(void *)&cmd_config_tunnel_udp_port_config,
> 

Re: [dpdk-dev] [dpdk-dev v2 2/2] app/testpmd: add new UDP tunnel port for ecpri

[Guo, Jia]

> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Thursday, January 14, 2021 10:34 PM
> To: Guo, Jia <jia.guo@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>; Wu,
> Jingjing <jingjing.wu@intel.com>; Yang, Qiming <qiming.yang@intel.com>;
> Wang, Haiyue <haiyue.wang@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [dpdk-dev v2 2/2] app/testpmd: add new UDP
> tunnel port for ecpri
> 
> On 12/24/2020 6:59 AM, Jeff Guo wrote:
> > Add new UDP tunnel port params for ecpri configuration, the command as
> > below:
> >
> > testpmd> port config 0 udp_tunnel_port add ecpri 6789 port config 0
> > testpmd> udp_tunnel_port rm ecpri 6789
> >
> > Signed-off-by: Jeff Guo <jia.guo@intel.com>
> > ---
> >   app/test-pmd/cmdline.c | 7 +++++--
> >   1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> 
> Can you please update the 'cmd_help_long_parsed()' for command update,
> and update the testpmd documentation, 'testpmd_funcs.rst'?
> 

Oh, sure, that is what I should do for this patch set. Please expect next version.

> > index 2ccbaa039e..af08e48e2e 100644
> > --- a/app/test-pmd/cmdline.c
> > +++ b/app/test-pmd/cmdline.c
> > @@ -9175,6 +9175,8 @@ cmd_cfg_tunnel_udp_port_parsed(void
> *parsed_result,
> >   		tunnel_udp.prot_type = RTE_TUNNEL_TYPE_GENEVE;
> >   	} else if (!strcmp(res->tunnel_type, "vxlan-gpe")) {
> >   		tunnel_udp.prot_type = RTE_TUNNEL_TYPE_VXLAN_GPE;
> > +	} else if (!strcmp(res->tunnel_type, "ecpri")) {
> > +		tunnel_udp.prot_type = RTE_TUNNEL_TYPE_ECPRI;
> >   	} else {
> >   		printf("Invalid tunnel type\n");
> >   		return;
> > @@ -9209,7 +9211,7 @@ cmdline_parse_token_string_t
> cmd_config_tunnel_udp_port_action =
> >   				 "add#rm");
> >   cmdline_parse_token_string_t
> cmd_config_tunnel_udp_port_tunnel_type =
> >   	TOKEN_STRING_INITIALIZER(struct cmd_config_tunnel_udp_port,
> tunnel_type,
> > -				 "vxlan#geneve#vxlan-gpe");
> > +				 "vxlan#geneve#vxlan-gpe#ecpri");
> >   cmdline_parse_token_num_t cmd_config_tunnel_udp_port_value =
> >   	TOKEN_NUM_INITIALIZER(struct cmd_config_tunnel_udp_port,
> udp_port,
> >   			      RTE_UINT16);
> > @@ -9217,7 +9219,8 @@ cmdline_parse_token_num_t
> cmd_config_tunnel_udp_port_value =
> >   cmdline_parse_inst_t cmd_cfg_tunnel_udp_port = {
> >   	.f = cmd_cfg_tunnel_udp_port_parsed,
> >   	.data = NULL,
> > -	.help_str = "port config <port_id> udp_tunnel_port add|rm
> vxlan|geneve|vxlan-gpe <udp_port>",
> > +	.help_str = "port config <port_id> udp_tunnel_port add|rm vxlan|"
> > +		"geneve|vxlan-gpe|ecpri <udp_port>",
> >   	.tokens = {
> >   		(void *)&cmd_config_tunnel_udp_port_port,
> >   		(void *)&cmd_config_tunnel_udp_port_config,
> >

Re: [dpdk-dev] [dpdk-dev v2 0/2] add new UDP tunnel port for ecpri

[Zhang, Qi Z]

> -----Original Message-----
> From: Guo, Jia <jia.guo@intel.com>
> Sent: Thursday, December 24, 2020 3:00 PM
> To: Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>;
> Yang, Qiming <qiming.yang@intel.com>; Wang, Haiyue
> <haiyue.wang@intel.com>
> Cc: dev@dpdk.org; Guo, Jia <jia.guo@intel.com>
> Subject: [dpdk-dev v2 0/2] add new UDP tunnel port for ecpri
> 
> Add new UDP tunnel type and port params for ecpri configuration.
> 
> v2:
> separate patch set
> 
> Jeff Guo (2):
>   ethdev: add new tunnel type for ecpri
>   app/testpmd: add new UDP tunnel port for ecpri
> 
>  app/test-pmd/cmdline.c         | 7 +++++--
>  lib/librte_ethdev/rte_ethdev.h | 1 +
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> --
> 2.20.1

Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>

[dpdk-dev] [dpdk-dev v2 0/6] enable UDP ecpri configure in dcf

[Jeff Guo]

Enabling ecpri UDP tunnel port configure in dcf.

v2:
refactor PTYPE parsing and add related sharecode patch
separate patch set

Jeff Guo (6):
  net/ice/base: add package PTYPE enable information
  net/ice: refactor package type parsing
  net/ice/base: add new UDP tunnel type for ecpri
  net/ice: add PTYPE mapping for ecpri
  net/iavf: add PTYPE mapping for ecpri
  net/ice: enable ecpri tunnel port configure in dcf

 drivers/net/iavf/iavf_rxtx.c         |  44 +++++++++
 drivers/net/ice/base/ice_flex_pipe.c |  80 +++++++++++++++
 drivers/net/ice/base/ice_flex_pipe.h |   3 +
 drivers/net/ice/base/ice_flex_type.h |  20 ++++
 drivers/net/ice/base/ice_type.h      |   1 +
 drivers/net/ice/ice_acl_filter.c     |   3 +-
 drivers/net/ice/ice_dcf_ethdev.c     |  67 +++++++++++++
 drivers/net/ice/ice_fdir_filter.c    |  63 ++----------
 drivers/net/ice/ice_generic_flow.c   |  27 +++++-
 drivers/net/ice/ice_generic_flow.h   |   9 +-
 drivers/net/ice/ice_hash.c           |  47 ++-------
 drivers/net/ice/ice_rxtx.c           |  44 +++++++++
 drivers/net/ice/ice_switch_filter.c  | 139 +++------------------------
 13 files changed, 323 insertions(+), 224 deletions(-)

-- 
2.20.1

[dpdk-dev] [dpdk-dev v2 1/6] net/ice/base: add package PTYPE enable information

[Jeff Guo]

Scan the 'Marker PType TCAM' session to retrieve the Rx parser PTYPE
enable information from the current package.

Signed-off-by: Haiyue Wang <haiyue.wang@intel.com>
Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
 drivers/net/ice/base/ice_flex_pipe.c | 79 ++++++++++++++++++++++++++++
 drivers/net/ice/base/ice_flex_pipe.h |  3 ++
 drivers/net/ice/base/ice_flex_type.h | 19 +++++++
 drivers/net/ice/base/ice_type.h      |  1 +
 4 files changed, 102 insertions(+)

diff --git a/drivers/net/ice/base/ice_flex_pipe.c b/drivers/net/ice/base/ice_flex_pipe.c
index 7594df1696..987bea5623 100644
--- a/drivers/net/ice/base/ice_flex_pipe.c
+++ b/drivers/net/ice/base/ice_flex_pipe.c
@@ -315,6 +315,84 @@ ice_pkg_enum_entry(struct ice_seg *ice_seg, struct ice_pkg_enum *state,
 	return entry;
 }
 
+/**
+ * ice_hw_ptype_ena - check if the PTYPE is enabled or not
+ * @hw: pointer to the HW structure
+ * @ptype: the hardware PTYPE
+ */
+bool ice_hw_ptype_ena(struct ice_hw *hw, u16 ptype)
+{
+	return ptype < ICE_FLOW_PTYPE_MAX &&
+	       ice_is_bit_set(hw->hw_ptype, ptype);
+}
+
+/**
+ * ice_marker_ptype_tcam_handler
+ * @sect_type: section type
+ * @section: pointer to section
+ * @index: index of the Marker PType TCAM entry to be returned
+ * @offset: pointer to receive absolute offset, always 0 for ptype TCAM sections
+ *
+ * This is a callback function that can be passed to ice_pkg_enum_entry.
+ * Handles enumeration of individual Marker PType TCAM entries.
+ */
+static void *
+ice_marker_ptype_tcam_handler(u32 sect_type, void *section, u32 index,
+			      u32 *offset)
+{
+	struct ice_marker_ptype_tcam_section *marker_ptype;
+
+	if (!section)
+		return NULL;
+
+	if (sect_type != ICE_SID_RXPARSER_MARKER_PTYPE)
+		return NULL;
+
+	if (index > ICE_MAX_MARKER_PTYPE_TCAMS_IN_BUF)
+		return NULL;
+
+	if (offset)
+		*offset = 0;
+
+	marker_ptype = (struct ice_marker_ptype_tcam_section *)section;
+
+	if (index >= LE16_TO_CPU(marker_ptype->count))
+		return NULL;
+
+	return marker_ptype->tcam + index;
+}
+
+/**
+ * ice_fill_hw_ptype - fill the enabled PTYPE bit information
+ * @hw: pointer to the HW structure
+ */
+static void
+ice_fill_hw_ptype(struct ice_hw *hw)
+{
+	struct ice_marker_ptype_tcam_entry *tcam;
+	struct ice_seg *seg = hw->seg;
+	struct ice_pkg_enum state;
+
+	ice_zero_bitmap(hw->hw_ptype, ICE_FLOW_PTYPE_MAX);
+	if (!seg)
+		return;
+
+	ice_memset(&state, 0, sizeof(state), ICE_NONDMA_MEM);
+
+	do {
+		tcam = (struct ice_marker_ptype_tcam_entry *)
+			ice_pkg_enum_entry(seg, &state,
+					   ICE_SID_RXPARSER_MARKER_PTYPE, NULL,
+					   ice_marker_ptype_tcam_handler);
+		if (tcam &&
+		    LE16_TO_CPU(tcam->addr) < ICE_MARKER_PTYPE_TCAM_ADDR_MAX &&
+		    LE16_TO_CPU(tcam->ptype) < ICE_FLOW_PTYPE_MAX)
+			ice_set_bit(LE16_TO_CPU(tcam->ptype), hw->hw_ptype);
+
+		seg = NULL;
+	} while (tcam);
+}
+
 /**
  * ice_boost_tcam_handler
  * @sect_type: section type
@@ -1511,6 +1589,7 @@ enum ice_status ice_init_pkg(struct ice_hw *hw, u8 *buf, u32 len)
 		 */
 		ice_init_pkg_regs(hw);
 		ice_fill_blk_tbls(hw);
+		ice_fill_hw_ptype(hw);
 		ice_get_prof_index_max(hw);
 	} else {
 		ice_debug(hw, ICE_DBG_INIT, "package load failed, %d\n",
diff --git a/drivers/net/ice/base/ice_flex_pipe.h b/drivers/net/ice/base/ice_flex_pipe.h
index 214c7a2837..66965d0975 100644
--- a/drivers/net/ice/base/ice_flex_pipe.h
+++ b/drivers/net/ice/base/ice_flex_pipe.h
@@ -48,6 +48,9 @@ bool ice_tunnel_port_in_use(struct ice_hw *hw, u16 port, u16 *index);
 bool
 ice_tunnel_get_type(struct ice_hw *hw, u16 port, enum ice_tunnel_type *type);
 
+/* RX parser PType functions */
+bool ice_hw_ptype_ena(struct ice_hw *hw, u16 ptype);
+
 /* XLT2/VSI group functions */
 enum ice_status
 ice_vsig_find_vsi(struct ice_hw *hw, enum ice_block blk, u16 vsi, u16 *vsig);
diff --git a/drivers/net/ice/base/ice_flex_type.h b/drivers/net/ice/base/ice_flex_type.h
index 1dd57baccd..9213856ac1 100644
--- a/drivers/net/ice/base/ice_flex_type.h
+++ b/drivers/net/ice/base/ice_flex_type.h
@@ -472,6 +472,25 @@ struct ice_boost_tcam_section {
 	sizeof(struct ice_boost_tcam_entry), \
 	sizeof(struct ice_boost_tcam_entry))
 
+/* package Marker PType TCAM entry */
+struct ice_marker_ptype_tcam_entry {
+#define ICE_MARKER_PTYPE_TCAM_ADDR_MAX	1024
+	__le16 addr;
+	__le16 ptype;
+	u8 keys[20];
+};
+
+struct ice_marker_ptype_tcam_section {
+	__le16 count;
+	__le16 reserved;
+	struct ice_marker_ptype_tcam_entry tcam[STRUCT_HACK_VAR_LEN];
+};
+
+#define ICE_MAX_MARKER_PTYPE_TCAMS_IN_BUF ICE_MAX_ENTRIES_IN_BUF( \
+	ice_struct_size((struct ice_marker_ptype_tcam_section *)0, tcam, 1) - \
+	sizeof(struct ice_marker_ptype_tcam_entry), \
+	sizeof(struct ice_marker_ptype_tcam_entry))
+
 struct ice_xlt1_section {
 	__le16 count;
 	__le16 offset;
diff --git a/drivers/net/ice/base/ice_type.h b/drivers/net/ice/base/ice_type.h
index 6b8d44f0b4..8ba7ded9a2 100644
--- a/drivers/net/ice/base/ice_type.h
+++ b/drivers/net/ice/base/ice_type.h
@@ -985,6 +985,7 @@ struct ice_hw {
 	ice_declare_bitmap(fdir_perfect_fltr, ICE_FLTR_PTYPE_MAX);
 	struct ice_lock rss_locks;	/* protect RSS configuration */
 	struct LIST_HEAD_TYPE rss_list_head;
+	ice_declare_bitmap(hw_ptype, ICE_FLOW_PTYPE_MAX);
 };
 
 /* Statistics collected by each port, VSI, VEB, and S-channel */
-- 
2.20.1

[dpdk-dev] [dpdk-dev v2 2/6] net/ice: refactor package type parsing

[Jeff Guo]

If the PTYPE support of the package could be checked, no need to parse
different PTYPE list for each type of the package. So, refactor the
package type parsing mechanism in each flow engins.

Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
 drivers/net/ice/ice_acl_filter.c    |   3 +-
 drivers/net/ice/ice_fdir_filter.c   |  63 ++-----------
 drivers/net/ice/ice_generic_flow.c  |  27 +++++-
 drivers/net/ice/ice_generic_flow.h  |   9 +-
 drivers/net/ice/ice_hash.c          |  47 ++--------
 drivers/net/ice/ice_switch_filter.c | 139 ++++------------------------
 6 files changed, 64 insertions(+), 224 deletions(-)

diff --git a/drivers/net/ice/ice_acl_filter.c b/drivers/net/ice/ice_acl_filter.c
index f7dbe53574..363ce68318 100644
--- a/drivers/net/ice/ice_acl_filter.c
+++ b/drivers/net/ice/ice_acl_filter.c
@@ -914,7 +914,8 @@ ice_acl_parse(struct ice_adapter *ad,
 	int ret;
 
 	memset(filter, 0, sizeof(*filter));
-	item = ice_search_pattern_match_item(pattern, array, array_len, error);
+	item = ice_search_pattern_match_item(ad, pattern, array, array_len,
+					     error);
 	if (!item)
 		return -rte_errno;
 
diff --git a/drivers/net/ice/ice_fdir_filter.c b/drivers/net/ice/ice_fdir_filter.c
index 175abcdd5c..ce6aa09d3d 100644
--- a/drivers/net/ice/ice_fdir_filter.c
+++ b/drivers/net/ice/ice_fdir_filter.c
@@ -84,34 +84,7 @@
 	ICE_INSET_IPV6_SRC | ICE_INSET_IPV6_DST | \
 	ICE_INSET_GTPU_TEID | ICE_INSET_GTPU_QFI)
 
-static struct ice_pattern_match_item ice_fdir_pattern_os[] = {
-	{pattern_eth_ipv4,             ICE_FDIR_INSET_ETH_IPV4,              ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp,         ICE_FDIR_INSET_ETH_IPV4_UDP,          ICE_INSET_NONE},
-	{pattern_eth_ipv4_tcp,         ICE_FDIR_INSET_ETH_IPV4_TCP,          ICE_INSET_NONE},
-	{pattern_eth_ipv4_sctp,        ICE_FDIR_INSET_ETH_IPV4_SCTP,         ICE_INSET_NONE},
-	{pattern_eth_ipv6,             ICE_FDIR_INSET_ETH_IPV6,              ICE_INSET_NONE},
-	{pattern_eth_ipv6_udp,         ICE_FDIR_INSET_ETH_IPV6_UDP,          ICE_INSET_NONE},
-	{pattern_eth_ipv6_tcp,         ICE_FDIR_INSET_ETH_IPV6_TCP,          ICE_INSET_NONE},
-	{pattern_eth_ipv6_sctp,        ICE_FDIR_INSET_ETH_IPV6_SCTP,         ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_ipv4,
-				       ICE_FDIR_INSET_VXLAN_IPV4,            ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_ipv4_udp,
-				       ICE_FDIR_INSET_VXLAN_IPV4_UDP,        ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_ipv4_tcp,
-				       ICE_FDIR_INSET_VXLAN_IPV4_TCP,        ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_ipv4_sctp,
-				       ICE_FDIR_INSET_VXLAN_IPV4_SCTP,       ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4,
-				       ICE_FDIR_INSET_VXLAN_IPV4,            ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_udp,
-				       ICE_FDIR_INSET_VXLAN_IPV4_UDP,        ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_tcp,
-				       ICE_FDIR_INSET_VXLAN_IPV4_TCP,        ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_sctp,
-				       ICE_FDIR_INSET_VXLAN_IPV4_SCTP,       ICE_INSET_NONE},
-};
-
-static struct ice_pattern_match_item ice_fdir_pattern_comms[] = {
+static struct ice_pattern_match_item ice_fdir_pattern_list[] = {
 	{pattern_ethertype,	       ICE_FDIR_INSET_ETH,		     ICE_INSET_NONE},
 	{pattern_eth_ipv4,             ICE_FDIR_INSET_ETH_IPV4,              ICE_INSET_NONE},
 	{pattern_eth_ipv4_udp,         ICE_FDIR_INSET_ETH_IPV4_UDP,          ICE_INSET_NONE},
@@ -143,8 +116,7 @@ static struct ice_pattern_match_item ice_fdir_pattern_comms[] = {
 	{pattern_eth_ipv6_gtpu_eh,     ICE_FDIR_INSET_IPV6_GTPU_EH,          ICE_INSET_NONE},
 };
 
-static struct ice_flow_parser ice_fdir_parser_os;
-static struct ice_flow_parser ice_fdir_parser_comms;
+static struct ice_flow_parser ice_fdir_parser;
 
 static int
 ice_fdir_is_tunnel_profile(enum ice_fdir_tunnel_type tunnel_type);
@@ -1111,12 +1083,7 @@ ice_fdir_init(struct ice_adapter *ad)
 	if (ret)
 		return ret;
 
-	if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
-		parser = &ice_fdir_parser_comms;
-	else if (ad->active_pkg_type == ICE_PKG_TYPE_OS_DEFAULT)
-		parser = &ice_fdir_parser_os;
-	else
-		return -EINVAL;
+	parser = &ice_fdir_parser;
 
 	return ice_register_parser(parser, ad);
 }
@@ -1124,16 +1091,13 @@ ice_fdir_init(struct ice_adapter *ad)
 static void
 ice_fdir_uninit(struct ice_adapter *ad)
 {
-	struct ice_pf *pf = &ad->pf;
 	struct ice_flow_parser *parser;
+	struct ice_pf *pf = &ad->pf;
 
 	if (ad->hw.dcf_enabled)
 		return;
 
-	if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
-		parser = &ice_fdir_parser_comms;
-	else
-		parser = &ice_fdir_parser_os;
+	parser = &ice_fdir_parser;
 
 	ice_unregister_parser(parser, ad);
 
@@ -2039,7 +2003,8 @@ ice_fdir_parse(struct ice_adapter *ad,
 	int ret;
 
 	memset(filter, 0, sizeof(*filter));
-	item = ice_search_pattern_match_item(pattern, array, array_len, error);
+	item = ice_search_pattern_match_item(ad, pattern, array, array_len,
+					     error);
 	if (!item)
 		return -rte_errno;
 
@@ -2067,18 +2032,10 @@ ice_fdir_parse(struct ice_adapter *ad,
 	return ret;
 }
 
-static struct ice_flow_parser ice_fdir_parser_os = {
-	.engine = &ice_fdir_engine,
-	.array = ice_fdir_pattern_os,
-	.array_len = RTE_DIM(ice_fdir_pattern_os),
-	.parse_pattern_action = ice_fdir_parse,
-	.stage = ICE_FLOW_STAGE_DISTRIBUTOR,
-};
-
-static struct ice_flow_parser ice_fdir_parser_comms = {
+static struct ice_flow_parser ice_fdir_parser = {
 	.engine = &ice_fdir_engine,
-	.array = ice_fdir_pattern_comms,
-	.array_len = RTE_DIM(ice_fdir_pattern_comms),
+	.array = ice_fdir_pattern_list,
+	.array_len = RTE_DIM(ice_fdir_pattern_list),
 	.parse_pattern_action = ice_fdir_parse,
 	.stage = ICE_FLOW_STAGE_DISTRIBUTOR,
 };
diff --git a/drivers/net/ice/ice_generic_flow.c b/drivers/net/ice/ice_generic_flow.c
index 1429cbc3b6..34a209af9d 100644
--- a/drivers/net/ice/ice_generic_flow.c
+++ b/drivers/net/ice/ice_generic_flow.c
@@ -2029,6 +2029,21 @@ ice_pattern_skip_void_item(struct rte_flow_item *items,
 	rte_memcpy(items, pe, sizeof(struct rte_flow_item));
 }
 
+static bool
+ice_pattern_is_support(__rte_unused struct ice_adapter *ad,
+		       const struct rte_flow_item *pattern)
+{
+	const struct rte_flow_item *pb = pattern;
+
+	while (pb != RTE_FLOW_ITEM_TYPE_END) {
+		if (!ice_hw_ptype_ena(&ad->hw, pb->type))
+			return false;
+		pb++;
+	}
+
+	return true;
+}
+
 /* Check if the pattern matches a supported item type array */
 static bool
 ice_match_pattern(enum rte_flow_item_type *item_array,
@@ -2047,10 +2062,11 @@ ice_match_pattern(enum rte_flow_item_type *item_array,
 }
 
 struct ice_pattern_match_item *
-ice_search_pattern_match_item(const struct rte_flow_item pattern[],
-		struct ice_pattern_match_item *array,
-		uint32_t array_len,
-		struct rte_flow_error *error)
+ice_search_pattern_match_item(struct ice_adapter *ad,
+			      const struct rte_flow_item pattern[],
+			      struct ice_pattern_match_item *array,
+			      uint32_t array_len,
+			      struct rte_flow_error *error)
 {
 	uint16_t i = 0;
 	struct ice_pattern_match_item *pattern_match_item;
@@ -2083,6 +2099,9 @@ ice_search_pattern_match_item(const struct rte_flow_item pattern[],
 
 	ice_pattern_skip_void_item(items, pattern);
 
+	if (!ice_pattern_is_support(ad, pattern))
+		return NULL;
+
 	for (i = 0; i < array_len; i++)
 		if (ice_match_pattern(array[i].pattern_list,
 					items)) {
diff --git a/drivers/net/ice/ice_generic_flow.h b/drivers/net/ice/ice_generic_flow.h
index 434d2f425d..0dcb620809 100644
--- a/drivers/net/ice/ice_generic_flow.h
+++ b/drivers/net/ice/ice_generic_flow.h
@@ -593,10 +593,11 @@ int ice_register_parser(struct ice_flow_parser *parser,
 void ice_unregister_parser(struct ice_flow_parser *parser,
 		struct ice_adapter *ad);
 struct ice_pattern_match_item *
-ice_search_pattern_match_item(const struct rte_flow_item pattern[],
-		struct ice_pattern_match_item *array,
-		uint32_t array_len,
-		struct rte_flow_error *error);
+ice_search_pattern_match_item(struct ice_adapter *ad,
+			      const struct rte_flow_item pattern[],
+			      struct ice_pattern_match_item *array,
+			      uint32_t array_len,
+			      struct rte_flow_error *error);
 int
 ice_flow_redirect(struct ice_adapter *ad,
 		  struct ice_flow_redirect *rd);
diff --git a/drivers/net/ice/ice_hash.c b/drivers/net/ice/ice_hash.c
index fe3e06c579..fab2d397b7 100644
--- a/drivers/net/ice/ice_hash.c
+++ b/drivers/net/ice/ice_hash.c
@@ -313,21 +313,7 @@ struct rss_type_match_hdr hint_eth_pppoes = {
 	ICE_FLOW_SEG_HDR_PPPOE,
 	ETH_RSS_ETH | ETH_RSS_PPPOE};
 
-/* Supported pattern for os default package. */
-static struct ice_pattern_match_item ice_hash_pattern_list_os[] = {
-	{pattern_eth_ipv4,	ICE_INSET_NONE,	&hint_eth_ipv4},
-	{pattern_eth_ipv4_udp,	ICE_INSET_NONE,	&hint_eth_ipv4_udp},
-	{pattern_eth_ipv4_tcp,	ICE_INSET_NONE,	&hint_eth_ipv4_tcp},
-	{pattern_eth_ipv4_sctp,	ICE_INSET_NONE,	&hint_eth_ipv4_sctp},
-	{pattern_eth_ipv6,	ICE_INSET_NONE,	&hint_eth_ipv6},
-	{pattern_eth_ipv6_udp,	ICE_INSET_NONE,	&hint_eth_ipv6_udp},
-	{pattern_eth_ipv6_tcp,	ICE_INSET_NONE,	&hint_eth_ipv6_tcp},
-	{pattern_eth_ipv6_sctp,	ICE_INSET_NONE,	&hint_eth_ipv6_sctp},
-	{pattern_empty,		ICE_INSET_NONE,	&hint_empty},
-};
-
-/* Supported pattern for comms package. */
-static struct ice_pattern_match_item ice_hash_pattern_list_comms[] = {
+static struct ice_pattern_match_item ice_hash_pattern_list[] = {
 	{pattern_empty,			    ICE_INSET_NONE,
 		&hint_empty},
 	{pattern_eth_ipv4,		    ICE_INSET_NONE,
@@ -915,19 +901,10 @@ static struct ice_flow_engine ice_hash_engine = {
 };
 
 /* Register parser for os package. */
-static struct ice_flow_parser ice_hash_parser_os = {
-	.engine = &ice_hash_engine,
-	.array = ice_hash_pattern_list_os,
-	.array_len = RTE_DIM(ice_hash_pattern_list_os),
-	.parse_pattern_action = ice_hash_parse_pattern_action,
-	.stage = ICE_FLOW_STAGE_RSS,
-};
-
-/* Register parser for comms package. */
-static struct ice_flow_parser ice_hash_parser_comms = {
+static struct ice_flow_parser ice_hash_parser = {
 	.engine = &ice_hash_engine,
-	.array = ice_hash_pattern_list_comms,
-	.array_len = RTE_DIM(ice_hash_pattern_list_comms),
+	.array = ice_hash_pattern_list,
+	.array_len = RTE_DIM(ice_hash_pattern_list),
 	.parse_pattern_action = ice_hash_parse_pattern_action,
 	.stage = ICE_FLOW_STAGE_RSS,
 };
@@ -946,12 +923,7 @@ ice_hash_init(struct ice_adapter *ad)
 	if (ad->hw.dcf_enabled)
 		return 0;
 
-	if (ad->active_pkg_type == ICE_PKG_TYPE_OS_DEFAULT)
-		parser = &ice_hash_parser_os;
-	else if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
-		parser = &ice_hash_parser_comms;
-	else
-		return -EINVAL;
+	parser = &ice_hash_parser;
 
 	return ice_register_parser(parser, ad);
 }
@@ -1211,8 +1183,8 @@ ice_hash_parse_pattern_action(__rte_unused struct ice_adapter *ad,
 	}
 
 	/* Check rss supported pattern and find matched pattern. */
-	pattern_match_item = ice_search_pattern_match_item(pattern,
-					array, array_len, error);
+	pattern_match_item = ice_search_pattern_match_item(ad, pattern, array,
+							   array_len, error);
 	if (!pattern_match_item) {
 		ret = -rte_errno;
 		goto error;
@@ -1352,10 +1324,7 @@ ice_hash_uninit(struct ice_adapter *ad)
 	if (ad->hw.dcf_enabled)
 		return;
 
-	if (ad->active_pkg_type == ICE_PKG_TYPE_OS_DEFAULT)
-		ice_unregister_parser(&ice_hash_parser_os, ad);
-	else if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
-		ice_unregister_parser(&ice_hash_parser_comms, ad);
+	ice_unregister_parser(&ice_hash_parser, ad);
 }
 
 static void
diff --git a/drivers/net/ice/ice_switch_filter.c b/drivers/net/ice/ice_switch_filter.c
index 8cba6eb7b1..e5b7d56068 100644
--- a/drivers/net/ice/ice_switch_filter.c
+++ b/drivers/net/ice/ice_switch_filter.c
@@ -137,47 +137,11 @@ struct sw_meta {
 	struct ice_adv_rule_info rule_info;
 };
 
-static struct ice_flow_parser ice_switch_dist_parser_os;
-static struct ice_flow_parser ice_switch_dist_parser_comms;
-static struct ice_flow_parser ice_switch_perm_parser_os;
-static struct ice_flow_parser ice_switch_perm_parser_comms;
+static struct ice_flow_parser ice_switch_dist_parser;
+static struct ice_flow_parser ice_switch_perm_parser;
 
 static struct
-ice_pattern_match_item ice_switch_pattern_dist_os[] = {
-	{pattern_ethertype,
-			ICE_SW_INSET_ETHER, ICE_INSET_NONE},
-	{pattern_ethertype_vlan,
-			ICE_SW_INSET_MAC_VLAN, ICE_INSET_NONE},
-	{pattern_eth_arp,
-			ICE_INSET_NONE, ICE_INSET_NONE},
-	{pattern_eth_ipv4,
-			ICE_SW_INSET_MAC_IPV4, ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp,
-			ICE_SW_INSET_MAC_IPV4_UDP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_tcp,
-			ICE_SW_INSET_MAC_IPV4_TCP, ICE_INSET_NONE},
-	{pattern_eth_ipv6,
-			ICE_SW_INSET_MAC_IPV6, ICE_INSET_NONE},
-	{pattern_eth_ipv6_udp,
-			ICE_SW_INSET_MAC_IPV6_UDP, ICE_INSET_NONE},
-	{pattern_eth_ipv6_tcp,
-			ICE_SW_INSET_MAC_IPV6_TCP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4,
-			ICE_SW_INSET_DIST_VXLAN_IPV4, ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_udp,
-			ICE_SW_INSET_DIST_VXLAN_IPV4_UDP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_tcp,
-			ICE_SW_INSET_DIST_VXLAN_IPV4_TCP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_nvgre_eth_ipv4,
-			ICE_SW_INSET_DIST_NVGRE_IPV4, ICE_INSET_NONE},
-	{pattern_eth_ipv4_nvgre_eth_ipv4_udp,
-			ICE_SW_INSET_DIST_NVGRE_IPV4_UDP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_nvgre_eth_ipv4_tcp,
-			ICE_SW_INSET_DIST_NVGRE_IPV4_TCP, ICE_INSET_NONE},
-};
-
-static struct
-ice_pattern_match_item ice_switch_pattern_dist_comms[] = {
+ice_pattern_match_item ice_switch_pattern_dist_list[] = {
 	{pattern_ethertype,
 			ICE_SW_INSET_ETHER, ICE_INSET_NONE},
 	{pattern_ethertype_vlan,
@@ -265,41 +229,7 @@ ice_pattern_match_item ice_switch_pattern_dist_comms[] = {
 };
 
 static struct
-ice_pattern_match_item ice_switch_pattern_perm_os[] = {
-	{pattern_ethertype,
-			ICE_SW_INSET_ETHER, ICE_INSET_NONE},
-	{pattern_ethertype_vlan,
-			ICE_SW_INSET_MAC_VLAN, ICE_INSET_NONE},
-	{pattern_eth_arp,
-			ICE_INSET_NONE, ICE_INSET_NONE},
-	{pattern_eth_ipv4,
-			ICE_SW_INSET_MAC_IPV4, ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp,
-			ICE_SW_INSET_MAC_IPV4_UDP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_tcp,
-			ICE_SW_INSET_MAC_IPV4_TCP, ICE_INSET_NONE},
-	{pattern_eth_ipv6,
-			ICE_SW_INSET_MAC_IPV6, ICE_INSET_NONE},
-	{pattern_eth_ipv6_udp,
-			ICE_SW_INSET_MAC_IPV6_UDP, ICE_INSET_NONE},
-	{pattern_eth_ipv6_tcp,
-			ICE_SW_INSET_MAC_IPV6_TCP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4,
-			ICE_SW_INSET_PERM_TUNNEL_IPV4, ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_udp,
-			ICE_SW_INSET_PERM_TUNNEL_IPV4_UDP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_tcp,
-			ICE_SW_INSET_PERM_TUNNEL_IPV4_TCP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_nvgre_eth_ipv4,
-			ICE_SW_INSET_PERM_TUNNEL_IPV4, ICE_INSET_NONE},
-	{pattern_eth_ipv4_nvgre_eth_ipv4_udp,
-			ICE_SW_INSET_PERM_TUNNEL_IPV4_UDP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_nvgre_eth_ipv4_tcp,
-			ICE_SW_INSET_PERM_TUNNEL_IPV4_TCP, ICE_INSET_NONE},
-};
-
-static struct
-ice_pattern_match_item ice_switch_pattern_perm_comms[] = {
+ice_pattern_match_item ice_switch_pattern_perm_list[] = {
 	{pattern_ethertype,
 			ICE_SW_INSET_ETHER, ICE_INSET_NONE},
 	{pattern_ethertype_vlan,
@@ -1699,7 +1629,8 @@ ice_switch_parse_pattern_action(struct ice_adapter *ad,
 	}
 
 	pattern_match_item =
-		ice_search_pattern_match_item(pattern, array, array_len, error);
+		ice_search_pattern_match_item(ad, pattern, array, array_len,
+					      error);
 	if (!pattern_match_item) {
 		rte_flow_error_set(error, EINVAL,
 				   RTE_FLOW_ERROR_TYPE_HANDLE, NULL,
@@ -1859,21 +1790,11 @@ ice_switch_init(struct ice_adapter *ad)
 	struct ice_flow_parser *dist_parser;
 	struct ice_flow_parser *perm_parser;
 
-	if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
-		dist_parser = &ice_switch_dist_parser_comms;
-	else if (ad->active_pkg_type == ICE_PKG_TYPE_OS_DEFAULT)
-		dist_parser = &ice_switch_dist_parser_os;
-	else
-		return -EINVAL;
-
 	if (ad->devargs.pipe_mode_support) {
-		if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
-			perm_parser = &ice_switch_perm_parser_comms;
-		else
-			perm_parser = &ice_switch_perm_parser_os;
-
+		perm_parser = &ice_switch_perm_parser;
 		ret = ice_register_parser(perm_parser, ad);
 	} else {
+		dist_parser = &ice_switch_dist_parser;
 		ret = ice_register_parser(dist_parser, ad);
 	}
 	return ret;
@@ -1885,21 +1806,11 @@ ice_switch_uninit(struct ice_adapter *ad)
 	struct ice_flow_parser *dist_parser;
 	struct ice_flow_parser *perm_parser;
 
-	if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
-		dist_parser = &ice_switch_dist_parser_comms;
-	else if (ad->active_pkg_type == ICE_PKG_TYPE_OS_DEFAULT)
-		dist_parser = &ice_switch_dist_parser_os;
-	else
-		return;
-
 	if (ad->devargs.pipe_mode_support) {
-		if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
-			perm_parser = &ice_switch_perm_parser_comms;
-		else
-			perm_parser = &ice_switch_perm_parser_os;
-
+		perm_parser = &ice_switch_perm_parser;
 		ice_unregister_parser(perm_parser, ad);
 	} else {
+		dist_parser = &ice_switch_dist_parser;
 		ice_unregister_parser(dist_parser, ad);
 	}
 }
@@ -1917,37 +1828,19 @@ ice_flow_engine ice_switch_engine = {
 };
 
 static struct
-ice_flow_parser ice_switch_dist_parser_os = {
+ice_flow_parser ice_switch_dist_parser = {
 	.engine = &ice_switch_engine,
-	.array = ice_switch_pattern_dist_os,
-	.array_len = RTE_DIM(ice_switch_pattern_dist_os),
+	.array = ice_switch_pattern_dist_list,
+	.array_len = RTE_DIM(ice_switch_pattern_dist_list),
 	.parse_pattern_action = ice_switch_parse_pattern_action,
 	.stage = ICE_FLOW_STAGE_DISTRIBUTOR,
 };
 
 static struct
-ice_flow_parser ice_switch_dist_parser_comms = {
-	.engine = &ice_switch_engine,
-	.array = ice_switch_pattern_dist_comms,
-	.array_len = RTE_DIM(ice_switch_pattern_dist_comms),
-	.parse_pattern_action = ice_switch_parse_pattern_action,
-	.stage = ICE_FLOW_STAGE_DISTRIBUTOR,
-};
-
-static struct
-ice_flow_parser ice_switch_perm_parser_os = {
-	.engine = &ice_switch_engine,
-	.array = ice_switch_pattern_perm_os,
-	.array_len = RTE_DIM(ice_switch_pattern_perm_os),
-	.parse_pattern_action = ice_switch_parse_pattern_action,
-	.stage = ICE_FLOW_STAGE_PERMISSION,
-};
-
-static struct
-ice_flow_parser ice_switch_perm_parser_comms = {
+ice_flow_parser ice_switch_perm_parser = {
 	.engine = &ice_switch_engine,
-	.array = ice_switch_pattern_perm_comms,
-	.array_len = RTE_DIM(ice_switch_pattern_perm_comms),
+	.array = ice_switch_pattern_perm_list,
+	.array_len = RTE_DIM(ice_switch_pattern_perm_list),
 	.parse_pattern_action = ice_switch_parse_pattern_action,
 	.stage = ICE_FLOW_STAGE_PERMISSION,
 };
-- 
2.20.1

[dpdk-dev] [dpdk-dev v2 3/6] net/ice/base: add new UDP tunnel type for ecpri

[Jeff Guo]

Add new UDP tunnel type for ecpri.

Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
 drivers/net/ice/base/ice_flex_pipe.c | 1 +
 drivers/net/ice/base/ice_flex_type.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/net/ice/base/ice_flex_pipe.c b/drivers/net/ice/base/ice_flex_pipe.c
index 987bea5623..31a4695343 100644
--- a/drivers/net/ice/base/ice_flex_pipe.c
+++ b/drivers/net/ice/base/ice_flex_pipe.c
@@ -13,6 +13,7 @@
 static const struct ice_tunnel_type_scan tnls[] = {
 	{ TNL_VXLAN,		"TNL_VXLAN_PF" },
 	{ TNL_GENEVE,		"TNL_GENEVE_PF" },
+	{ TNL_ECPRI,		"TNL_UDP_ECPRI_PF" },
 	{ TNL_LAST,		"" }
 };
 
diff --git a/drivers/net/ice/base/ice_flex_type.h b/drivers/net/ice/base/ice_flex_type.h
index 9213856ac1..f75a1005f3 100644
--- a/drivers/net/ice/base/ice_flex_type.h
+++ b/drivers/net/ice/base/ice_flex_type.h
@@ -535,6 +535,7 @@ struct ice_pkg_enum {
 enum ice_tunnel_type {
 	TNL_VXLAN = 0,
 	TNL_GENEVE,
+	TNL_ECPRI,
 	TNL_LAST = 0xFF,
 	TNL_ALL = 0xFF,
 };
-- 
2.20.1

[dpdk-dev] [dpdk-dev v2 4/6] net/ice: add PTYPE mapping for ecpri

[Jeff Guo]

Until the new ecpri PTYPE be added into the RTE lib, just mapping ecpri
to the PTYPE of RTE_PTYPE_L4_UDP in ice pmd.

Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
 drivers/net/ice/ice_rxtx.c | 44 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/drivers/net/ice/ice_rxtx.c b/drivers/net/ice/ice_rxtx.c
index d052bd0f1b..95be6f6791 100644
--- a/drivers/net/ice/ice_rxtx.c
+++ b/drivers/net/ice/ice_rxtx.c
@@ -3880,6 +3880,50 @@ ice_get_default_pkt_type(uint16_t ptype)
 			RTE_PTYPE_TUNNEL_GTPU |
 			RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN |
 			RTE_PTYPE_INNER_L4_ICMP,
+
+		/* IPv4 --> UDP ECPRI */
+		[372] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[373] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[374] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[375] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[376] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[377] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[378] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[379] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[380] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[381] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+
+		/* IPV6 --> UDP ECPRI */
+		[382] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[383] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[384] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[385] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[386] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[387] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[388] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[389] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[390] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[391] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
 		/* All others reserved */
 	};
 
-- 
2.20.1

[dpdk-dev] [dpdk-dev v2 5/6] net/iavf: add PTYPE mapping for ecpri

[Jeff Guo]

Until the new ecpri PTYPE be added into the RTE lib, just mapping ecpri
to the PTYPE of RTE_PTYPE_L4_UDP in iavf pmd.

Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
 drivers/net/iavf/iavf_rxtx.c | 44 ++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/drivers/net/iavf/iavf_rxtx.c b/drivers/net/iavf/iavf_rxtx.c
index 21d508b3f4..2800dd6250 100644
--- a/drivers/net/iavf/iavf_rxtx.c
+++ b/drivers/net/iavf/iavf_rxtx.c
@@ -3193,6 +3193,50 @@ iavf_get_default_ptype_table(void)
 			RTE_PTYPE_TUNNEL_GTPU |
 			RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN |
 			RTE_PTYPE_INNER_L4_ICMP,
+
+		/* IPv4 --> UDP ECPRI */
+		[372] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[373] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[374] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[375] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[376] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[377] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[378] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[379] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[380] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[381] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+
+		/* IPV6 --> UDP ECPRI */
+		[382] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[383] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[384] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[385] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[386] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[387] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[388] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[389] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[390] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[391] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
 		/* All others reserved */
 	};
 
-- 
2.20.1

[dpdk-dev] [dpdk-dev v2 6/6] net/ice: enable ecpri tunnel port configure in dcf

[Jeff Guo]

Add ecpri tunnel port add and rm ops to configure ecpri udp tunnel port
in dcf.

Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
 drivers/net/ice/ice_dcf_ethdev.c | 67 ++++++++++++++++++++++++++++++++
 1 file changed, 67 insertions(+)

diff --git a/drivers/net/ice/ice_dcf_ethdev.c b/drivers/net/ice/ice_dcf_ethdev.c
index b0b2ecb0d6..08265db79f 100644
--- a/drivers/net/ice/ice_dcf_ethdev.c
+++ b/drivers/net/ice/ice_dcf_ethdev.c
@@ -26,6 +26,13 @@
 #include "ice_dcf_ethdev.h"
 #include "ice_rxtx.h"
 
+static int
+ice_dcf_dev_udp_tunnel_port_add(struct rte_eth_dev *dev,
+				struct rte_eth_udp_tunnel *udp_tunnel);
+static int
+ice_dcf_dev_udp_tunnel_port_del(struct rte_eth_dev *dev,
+				struct rte_eth_udp_tunnel *udp_tunnel);
+
 static uint16_t
 ice_dcf_recv_pkts(__rte_unused void *rx_queue,
 		  __rte_unused struct rte_mbuf **bufs,
@@ -870,6 +877,64 @@ ice_dcf_link_update(__rte_unused struct rte_eth_dev *dev,
 	return 0;
 }
 
+/* Add UDP tunneling port */
+static int
+ice_dcf_dev_udp_tunnel_port_add(struct rte_eth_dev *dev,
+				struct rte_eth_udp_tunnel *udp_tunnel)
+{
+	struct ice_dcf_adapter *adapter = dev->data->dev_private;
+	struct ice_adapter *parent_adapter = &adapter->parent;
+	struct ice_hw *parent_hw = &parent_adapter->hw;
+	int ret = 0;
+
+	if (!udp_tunnel)
+		return -EINVAL;
+
+	switch (udp_tunnel->prot_type) {
+	case RTE_TUNNEL_TYPE_VXLAN:
+		ret = ice_create_tunnel(parent_hw, TNL_VXLAN,
+					udp_tunnel->udp_port);
+		break;
+	case RTE_TUNNEL_TYPE_ECPRI:
+		ret = ice_create_tunnel(parent_hw, TNL_ECPRI,
+					udp_tunnel->udp_port);
+		break;
+	default:
+		PMD_DRV_LOG(ERR, "Invalid tunnel type");
+		ret = -EINVAL;
+		break;
+	}
+
+	return ret;
+}
+
+/* Delete UDP tunneling port */
+static int
+ice_dcf_dev_udp_tunnel_port_del(struct rte_eth_dev *dev,
+				struct rte_eth_udp_tunnel *udp_tunnel)
+{
+	struct ice_dcf_adapter *adapter = dev->data->dev_private;
+	struct ice_adapter *parent_adapter = &adapter->parent;
+	struct ice_hw *parent_hw = &parent_adapter->hw;
+	int ret = 0;
+
+	if (!udp_tunnel)
+		return -EINVAL;
+
+	switch (udp_tunnel->prot_type) {
+	case RTE_TUNNEL_TYPE_VXLAN:
+	case RTE_TUNNEL_TYPE_ECPRI:
+		ret = ice_destroy_tunnel(parent_hw, udp_tunnel->udp_port, 0);
+		break;
+	default:
+		PMD_DRV_LOG(ERR, "Invalid tunnel type");
+		ret = -EINVAL;
+		break;
+	}
+
+	return ret;
+}
+
 static const struct eth_dev_ops ice_dcf_eth_dev_ops = {
 	.dev_start               = ice_dcf_dev_start,
 	.dev_stop                = ice_dcf_dev_stop,
@@ -892,6 +957,8 @@ static const struct eth_dev_ops ice_dcf_eth_dev_ops = {
 	.allmulticast_enable     = ice_dcf_dev_allmulticast_enable,
 	.allmulticast_disable    = ice_dcf_dev_allmulticast_disable,
 	.filter_ctrl             = ice_dcf_dev_filter_ctrl,
+	.udp_tunnel_port_add	 = ice_dcf_dev_udp_tunnel_port_add,
+	.udp_tunnel_port_del	 = ice_dcf_dev_udp_tunnel_port_del,
 };
 
 static int
-- 
2.20.1

[dpdk-dev] [dpdk-dev v3 0/3] net/ice: refactor PTYPE parsing

[Jeff Guo]

If the capability of a PTYPE within a specific package could be
negotiated, no need to maintain a different PTYPE list for each
type of the package when parsing PTYPE. So refactor the PTYPE
parsing mechanism for each flow engines.

v3:
separate the patch set from the ecpri configure patch set

Jeff Guo (3):
  net/ice/base: add package PTYPE enable information
  net/ice/base: add PTYPE value
  net/ice: refactor PTYPE parsing

 drivers/net/ice/base/ice_flex_pipe.c |  79 ++++++++++++++
 drivers/net/ice/base/ice_flex_pipe.h |   3 +
 drivers/net/ice/base/ice_flex_type.h | 157 ++++++++++++++++++++-------
 drivers/net/ice/base/ice_type.h      |   1 +
 drivers/net/ice/ice_acl_filter.c     |   3 +-
 drivers/net/ice/ice_fdir_filter.c    |  63 ++---------
 drivers/net/ice/ice_generic_flow.c   | 132 ++++++++++++++++++++--
 drivers/net/ice/ice_generic_flow.h   |   9 +-
 drivers/net/ice/ice_hash.c           |  47 ++------
 drivers/net/ice/ice_switch_filter.c  | 139 +++---------------------
 10 files changed, 366 insertions(+), 267 deletions(-)

-- 
2.20.1

[dpdk-dev] [dpdk-dev v3 1/3] net/ice/base: add package PTYPE enable information

[Jeff Guo]

Scan the 'Marker PType TCAM' session to retrieve the Rx parser PTYPE
enable information from the current package.

Signed-off-by: Haiyue Wang <haiyue.wang@intel.com>
Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
 drivers/net/ice/base/ice_flex_pipe.c | 79 ++++++++++++++++++++++++++++
 drivers/net/ice/base/ice_flex_pipe.h |  3 ++
 drivers/net/ice/base/ice_flex_type.h | 19 +++++++
 drivers/net/ice/base/ice_type.h      |  1 +
 4 files changed, 102 insertions(+)

diff --git a/drivers/net/ice/base/ice_flex_pipe.c b/drivers/net/ice/base/ice_flex_pipe.c
index 96aed3b795..96628ae5dc 100644
--- a/drivers/net/ice/base/ice_flex_pipe.c
+++ b/drivers/net/ice/base/ice_flex_pipe.c
@@ -316,6 +316,84 @@ ice_pkg_enum_entry(struct ice_seg *ice_seg, struct ice_pkg_enum *state,
 	return entry;
 }
 
+/**
+ * ice_hw_ptype_ena - check if the PTYPE is enabled or not
+ * @hw: pointer to the HW structure
+ * @ptype: the hardware PTYPE
+ */
+bool ice_hw_ptype_ena(struct ice_hw *hw, u16 ptype)
+{
+	return ptype < ICE_FLOW_PTYPE_MAX &&
+	       ice_is_bit_set(hw->hw_ptype, ptype);
+}
+
+/**
+ * ice_marker_ptype_tcam_handler
+ * @sect_type: section type
+ * @section: pointer to section
+ * @index: index of the Marker PType TCAM entry to be returned
+ * @offset: pointer to receive absolute offset, always 0 for ptype TCAM sections
+ *
+ * This is a callback function that can be passed to ice_pkg_enum_entry.
+ * Handles enumeration of individual Marker PType TCAM entries.
+ */
+static void *
+ice_marker_ptype_tcam_handler(u32 sect_type, void *section, u32 index,
+			      u32 *offset)
+{
+	struct ice_marker_ptype_tcam_section *marker_ptype;
+
+	if (!section)
+		return NULL;
+
+	if (sect_type != ICE_SID_RXPARSER_MARKER_PTYPE)
+		return NULL;
+
+	if (index > ICE_MAX_MARKER_PTYPE_TCAMS_IN_BUF)
+		return NULL;
+
+	if (offset)
+		*offset = 0;
+
+	marker_ptype = (struct ice_marker_ptype_tcam_section *)section;
+
+	if (index >= LE16_TO_CPU(marker_ptype->count))
+		return NULL;
+
+	return marker_ptype->tcam + index;
+}
+
+/**
+ * ice_fill_hw_ptype - fill the enabled PTYPE bit information
+ * @hw: pointer to the HW structure
+ */
+static void
+ice_fill_hw_ptype(struct ice_hw *hw)
+{
+	struct ice_marker_ptype_tcam_entry *tcam;
+	struct ice_seg *seg = hw->seg;
+	struct ice_pkg_enum state;
+
+	ice_zero_bitmap(hw->hw_ptype, ICE_FLOW_PTYPE_MAX);
+	if (!seg)
+		return;
+
+	ice_memset(&state, 0, sizeof(state), ICE_NONDMA_MEM);
+
+	do {
+		tcam = (struct ice_marker_ptype_tcam_entry *)
+			ice_pkg_enum_entry(seg, &state,
+					   ICE_SID_RXPARSER_MARKER_PTYPE, NULL,
+					   ice_marker_ptype_tcam_handler);
+		if (tcam &&
+		    LE16_TO_CPU(tcam->addr) < ICE_MARKER_PTYPE_TCAM_ADDR_MAX &&
+		    LE16_TO_CPU(tcam->ptype) < ICE_FLOW_PTYPE_MAX)
+			ice_set_bit(LE16_TO_CPU(tcam->ptype), hw->hw_ptype);
+
+		seg = NULL;
+	} while (tcam);
+}
+
 /**
  * ice_boost_tcam_handler
  * @sect_type: section type
@@ -1541,6 +1619,7 @@ enum ice_status ice_init_pkg(struct ice_hw *hw, u8 *buf, u32 len)
 		 */
 		ice_init_pkg_regs(hw);
 		ice_fill_blk_tbls(hw);
+		ice_fill_hw_ptype(hw);
 		ice_get_prof_index_max(hw);
 	} else {
 		ice_debug(hw, ICE_DBG_INIT, "package load failed, %d\n",
diff --git a/drivers/net/ice/base/ice_flex_pipe.h b/drivers/net/ice/base/ice_flex_pipe.h
index d4679cc940..066ff95e13 100644
--- a/drivers/net/ice/base/ice_flex_pipe.h
+++ b/drivers/net/ice/base/ice_flex_pipe.h
@@ -54,6 +54,9 @@ bool ice_tunnel_port_in_use(struct ice_hw *hw, u16 port, u16 *index);
 bool
 ice_tunnel_get_type(struct ice_hw *hw, u16 port, enum ice_tunnel_type *type);
 
+/* RX parser PType functions */
+bool ice_hw_ptype_ena(struct ice_hw *hw, u16 ptype);
+
 /* XLT2/VSI group functions */
 enum ice_status
 ice_vsig_find_vsi(struct ice_hw *hw, enum ice_block blk, u16 vsi, u16 *vsig);
diff --git a/drivers/net/ice/base/ice_flex_type.h b/drivers/net/ice/base/ice_flex_type.h
index 62cc81b49c..9b9503b3ba 100644
--- a/drivers/net/ice/base/ice_flex_type.h
+++ b/drivers/net/ice/base/ice_flex_type.h
@@ -472,6 +472,25 @@ struct ice_boost_tcam_section {
 	sizeof(struct ice_boost_tcam_entry), \
 	sizeof(struct ice_boost_tcam_entry))
 
+/* package Marker PType TCAM entry */
+struct ice_marker_ptype_tcam_entry {
+#define ICE_MARKER_PTYPE_TCAM_ADDR_MAX	1024
+	__le16 addr;
+	__le16 ptype;
+	u8 keys[20];
+};
+
+struct ice_marker_ptype_tcam_section {
+	__le16 count;
+	__le16 reserved;
+	struct ice_marker_ptype_tcam_entry tcam[STRUCT_HACK_VAR_LEN];
+};
+
+#define ICE_MAX_MARKER_PTYPE_TCAMS_IN_BUF ICE_MAX_ENTRIES_IN_BUF( \
+	ice_struct_size((struct ice_marker_ptype_tcam_section *)0, tcam, 1) - \
+	sizeof(struct ice_marker_ptype_tcam_entry), \
+	sizeof(struct ice_marker_ptype_tcam_entry))
+
 struct ice_xlt1_section {
 	__le16 count;
 	__le16 offset;
diff --git a/drivers/net/ice/base/ice_type.h b/drivers/net/ice/base/ice_type.h
index bb2cfd07fd..86e93c34a1 100644
--- a/drivers/net/ice/base/ice_type.h
+++ b/drivers/net/ice/base/ice_type.h
@@ -995,6 +995,7 @@ struct ice_hw {
 	struct ice_lock rss_locks;	/* protect RSS configuration */
 	struct LIST_HEAD_TYPE rss_list_head;
 	struct ice_vlan_mode_ops vlan_mode_ops;
+	ice_declare_bitmap(hw_ptype, ICE_FLOW_PTYPE_MAX);
 };
 
 /* Statistics collected by each port, VSI, VEB, and S-channel */
-- 
2.20.1

[dpdk-dev] [dpdk-dev v3 2/3] net/ice/base: add PTYPE value

[Jeff Guo]

Add some macros for some PType value.

Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
 drivers/net/ice/base/ice_flex_type.h | 138 +++++++++++++++++++--------
 1 file changed, 99 insertions(+), 39 deletions(-)

diff --git a/drivers/net/ice/base/ice_flex_type.h b/drivers/net/ice/base/ice_flex_type.h
index 9b9503b3ba..da408ec49c 100644
--- a/drivers/net/ice/base/ice_flex_type.h
+++ b/drivers/net/ice/base/ice_flex_type.h
@@ -267,45 +267,105 @@ enum ice_sect {
 };
 
 /* Packet Type (PTYPE) values */
-#define ICE_PTYPE_MAC_PAY		1
-#define ICE_PTYPE_IPV4FRAG_PAY		22
-#define ICE_PTYPE_IPV4_PAY		23
-#define ICE_PTYPE_IPV4_UDP_PAY		24
-#define ICE_PTYPE_IPV4_TCP_PAY		26
-#define ICE_PTYPE_IPV4_SCTP_PAY		27
-#define ICE_PTYPE_IPV4_ICMP_PAY		28
-#define ICE_PTYPE_IPV6FRAG_PAY		88
-#define ICE_PTYPE_IPV6_PAY		89
-#define ICE_PTYPE_IPV6_UDP_PAY		90
-#define ICE_PTYPE_IPV6_TCP_PAY		92
-#define ICE_PTYPE_IPV6_SCTP_PAY		93
-#define ICE_PTYPE_IPV6_ICMP_PAY		94
-#define ICE_MAC_IPV4_GTPC_TEID		325
-#define ICE_MAC_IPV6_GTPC_TEID		326
-#define ICE_MAC_IPV4_GTPC		327
-#define ICE_MAC_IPV6_GTPC		328
-#define ICE_MAC_IPV4_GTPU		329
-#define ICE_MAC_IPV6_GTPU		330
-#define ICE_MAC_IPV4_GTPU_IPV4_FRAG	331
-#define ICE_MAC_IPV4_GTPU_IPV4_PAY	332
-#define ICE_MAC_IPV4_GTPU_IPV4_UDP_PAY	333
-#define ICE_MAC_IPV4_GTPU_IPV4_TCP	334
-#define ICE_MAC_IPV4_GTPU_IPV4_ICMP	335
-#define ICE_MAC_IPV6_GTPU_IPV4_FRAG	336
-#define ICE_MAC_IPV6_GTPU_IPV4_PAY	337
-#define ICE_MAC_IPV6_GTPU_IPV4_UDP_PAY	338
-#define ICE_MAC_IPV6_GTPU_IPV4_TCP	339
-#define ICE_MAC_IPV6_GTPU_IPV4_ICMP	340
-#define ICE_MAC_IPV4_GTPU_IPV6_FRAG	341
-#define ICE_MAC_IPV4_GTPU_IPV6_PAY	342
-#define ICE_MAC_IPV4_GTPU_IPV6_UDP_PAY	343
-#define ICE_MAC_IPV4_GTPU_IPV6_TCP	344
-#define ICE_MAC_IPV4_GTPU_IPV6_ICMPV6	345
-#define ICE_MAC_IPV6_GTPU_IPV6_FRAG	346
-#define ICE_MAC_IPV6_GTPU_IPV6_PAY	347
-#define ICE_MAC_IPV6_GTPU_IPV6_UDP_PAY	348
-#define ICE_MAC_IPV6_GTPU_IPV6_TCP	349
-#define ICE_MAC_IPV6_GTPU_IPV6_ICMPV6	350
+#define ICE_PTYPE_MAC_PAY			1
+#define ICE_MAC_PTP				2
+#define ICE_MAC_LLDP				6
+#define ICE_MAC_ARP				11
+#define ICE_PTYPE_IPV4FRAG_PAY			22
+#define ICE_PTYPE_IPV4_PAY			23
+#define ICE_PTYPE_IPV4_UDP_PAY			24
+#define ICE_PTYPE_IPV4_TCP_PAY			26
+#define ICE_PTYPE_IPV4_SCTP_PAY			27
+#define ICE_PTYPE_IPV4_ICMP_PAY			28
+#define ICE_MAC_IPV4_TUN_PAY			43
+#define ICE_MAC_IPV4_TUN_IPV4_FRAG		44
+#define ICE_MAC_IPV4_TUN_IPV4_PAY		45
+#define ICE_MAC_IPV4_TUN_IPV4_UDP_PAY		46
+#define ICE_MAC_IPV4_TUN_IPV4_TCP		48
+#define ICE_MAC_IPV4_TUN_IPV4_SCTP		49
+#define ICE_MAC_IPV4_TUN_IPV4_ICMP		50
+#define ICE_MAC_IPV4_TUN_IPV6_FRAG		51
+#define ICE_MAC_IPV4_TUN_IPV6_PAY		52
+#define ICE_MAC_IPV4_TUN_IPV6_UDP_PAY		53
+#define ICE_MAC_IPV4_TUN_IPV6_TCP		55
+#define ICE_MAC_IPV4_TUN_IPV6_SCTP		56
+#define ICE_MAC_IPV4_TUN_IPV6_ICMPV6		57
+#define ICE_MAC_IPV4_TUN_ICE_MAC_PAY		58
+#define ICE_MAC_IPV4_TUN_ICE_MAC_IPV4_FRAG	59
+#define ICE_MAC_IPV4_TUN_ICE_MAC_IPV4_PAY	60
+#define ICE_MAC_IPV4_TUN_ICE_MAC_IPV4_UDP_PAY	61
+#define ICE_MAC_IPV4_TUN_ICE_MAC_IPV4_TCP	63
+#define ICE_MAC_IPV4_TUN_ICE_MAC_IPV4_SCTP	64
+#define ICE_MAC_IPV4_TUN_ICE_MAC_IPV4_ICMP	65
+#define ICE_MAC_IPV4_TUN_ICE_MAC_IPV6_FRAG	66
+#define ICE_MAC_IPV4_TUN_ICE_MAC_IPV6_PAY	67
+#define ICE_MAC_IPV4_TUN_ICE_MAC_IPV6_UDP_PAY	68
+#define ICE_MAC_IPV4_TUN_ICE_MAC_IPV6_TCP	70
+#define ICE_MAC_IPV4_TUN_ICE_MAC_IPV6_SCTP	71
+#define ICE_MAC_IPV4_TUN_ICE_MAC_IPV6_ICMPV6	72
+#define ICE_PTYPE_IPV6FRAG_PAY			88
+#define ICE_PTYPE_IPV6_PAY			89
+#define ICE_PTYPE_IPV6_UDP_PAY			90
+#define ICE_PTYPE_IPV6_TCP_PAY			92
+#define ICE_PTYPE_IPV6_SCTP_PAY			93
+#define ICE_PTYPE_IPV6_ICMP_PAY			94
+#define ICE_MAC_IPV4_ESP			160
+#define ICE_MAC_IPV6_ESP			161
+#define ICE_MAC_IPV4_AH				162
+#define ICE_MAC_IPV6_AH				163
+#define ICE_MAC_IPV4_NAT_T_ESP			164
+#define ICE_MAC_IPV6_NAT_T_ESP			165
+#define ICE_MAC_IPV4_NAT_T_IKE			166
+#define ICE_MAC_IPV6_NAT_T_IKE			167
+#define ICE_MAC_IPV4_NAT_T_KEEP			168
+#define ICE_MAC_IPV6_NAT_T_KEEP			169
+#define ICE_MAC_PPPOD_PAY			300
+#define ICE_MAC_PPPOE_PAY			301
+#define ICE_MAC_PPPOE_IPV4_FRAG			302
+#define ICE_MAC_PPPOE_IPV4_PAY			303
+#define ICE_MAC_PPPOE_IPV4_UDP_PAY		304
+#define ICE_MAC_PPPOE_IPV4_TCP			305
+#define ICE_MAC_PPPOE_IPV4_SCTP			306
+#define ICE_MAC_PPPOE_IPV4_ICMP			307
+#define ICE_MAC_PPPOE_IPV6_FRAG			308
+#define ICE_MAC_PPPOE_IPV6_PAY			309
+#define ICE_MAC_PPPOE_IPV6_UDP_PAY		310
+#define ICE_MAC_PPPOE_IPV6_TCP			311
+#define ICE_MAC_PPPOE_IPV6_SCTP			312
+#define ICE_MAC_PPPOE_IPV6_ICMPV6		313
+#define ICE_MAC_IPV4_GTPC_TEID			325
+#define ICE_MAC_IPV6_GTPC_TEID			326
+#define ICE_MAC_IPV4_GTPC			327
+#define ICE_MAC_IPV6_GTPC			328
+#define ICE_MAC_IPV4_GTPU			329
+#define ICE_MAC_IPV6_GTPU			330
+#define ICE_MAC_IPV4_GTPU_IPV4_FRAG		331
+#define ICE_MAC_IPV4_GTPU_IPV4_PAY		332
+#define ICE_MAC_IPV4_GTPU_IPV4_UDP_PAY		333
+#define ICE_MAC_IPV4_GTPU_IPV4_TCP		334
+#define ICE_MAC_IPV4_GTPU_IPV4_ICMP		335
+#define ICE_MAC_IPV6_GTPU_IPV4_FRAG		336
+#define ICE_MAC_IPV6_GTPU_IPV4_PAY		337
+#define ICE_MAC_IPV6_GTPU_IPV4_UDP_PAY		338
+#define ICE_MAC_IPV6_GTPU_IPV4_TCP		339
+#define ICE_MAC_IPV6_GTPU_IPV4_ICMP		340
+#define ICE_MAC_IPV4_GTPU_IPV6_FRAG		341
+#define ICE_MAC_IPV4_GTPU_IPV6_PAY		342
+#define ICE_MAC_IPV4_GTPU_IPV6_UDP_PAY		343
+#define ICE_MAC_IPV4_GTPU_IPV6_TCP		344
+#define ICE_MAC_IPV4_GTPU_IPV6_ICMPV6		345
+#define ICE_MAC_IPV6_GTPU_IPV6_FRAG		346
+#define ICE_MAC_IPV6_GTPU_IPV6_PAY		347
+#define ICE_MAC_IPV6_GTPU_IPV6_UDP_PAY		348
+#define ICE_MAC_IPV6_GTPU_IPV6_TCP		349
+#define ICE_MAC_IPV6_GTPU_IPV6_ICMPV6		350
+#define ICE_MAC_IPV4_PFCP_NODE			351
+#define ICE_MAC_IPV4_PFCP_SESSION		352
+#define ICE_MAC_IPV6_PFCP_NODE			353
+#define ICE_MAC_IPV6_PFCP_SESSION		354
+#define ICE_MAC_IPV4_L2TPV3			360
+#define ICE_MAC_IPV6_L2TPV3			361
+
 
 /* Attributes that can modify PTYPE definitions.
  *
-- 
2.20.1

[dpdk-dev] [dpdk-dev v3 3/3] net/ice: refactor PTYPE parsing

[Jeff Guo]

If the capability of a PTYPE within a specific package could be
negotiated, no need to maintain a different PTYPE list for each
type of the package when parsing PTYPE. So refactor the PTYPE
parsing mechanism for each flow engines.

Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
 drivers/net/ice/ice_acl_filter.c    |   3 +-
 drivers/net/ice/ice_fdir_filter.c   |  63 ++-----------
 drivers/net/ice/ice_generic_flow.c  | 132 ++++++++++++++++++++++++--
 drivers/net/ice/ice_generic_flow.h  |   9 +-
 drivers/net/ice/ice_hash.c          |  47 ++--------
 drivers/net/ice/ice_switch_filter.c | 139 ++++------------------------
 6 files changed, 165 insertions(+), 228 deletions(-)

diff --git a/drivers/net/ice/ice_acl_filter.c b/drivers/net/ice/ice_acl_filter.c
index f7dbe53574..363ce68318 100644
--- a/drivers/net/ice/ice_acl_filter.c
+++ b/drivers/net/ice/ice_acl_filter.c
@@ -914,7 +914,8 @@ ice_acl_parse(struct ice_adapter *ad,
 	int ret;
 
 	memset(filter, 0, sizeof(*filter));
-	item = ice_search_pattern_match_item(pattern, array, array_len, error);
+	item = ice_search_pattern_match_item(ad, pattern, array, array_len,
+					     error);
 	if (!item)
 		return -rte_errno;
 
diff --git a/drivers/net/ice/ice_fdir_filter.c b/drivers/net/ice/ice_fdir_filter.c
index 175abcdd5c..ce6aa09d3d 100644
--- a/drivers/net/ice/ice_fdir_filter.c
+++ b/drivers/net/ice/ice_fdir_filter.c
@@ -84,34 +84,7 @@
 	ICE_INSET_IPV6_SRC | ICE_INSET_IPV6_DST | \
 	ICE_INSET_GTPU_TEID | ICE_INSET_GTPU_QFI)
 
-static struct ice_pattern_match_item ice_fdir_pattern_os[] = {
-	{pattern_eth_ipv4,             ICE_FDIR_INSET_ETH_IPV4,              ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp,         ICE_FDIR_INSET_ETH_IPV4_UDP,          ICE_INSET_NONE},
-	{pattern_eth_ipv4_tcp,         ICE_FDIR_INSET_ETH_IPV4_TCP,          ICE_INSET_NONE},
-	{pattern_eth_ipv4_sctp,        ICE_FDIR_INSET_ETH_IPV4_SCTP,         ICE_INSET_NONE},
-	{pattern_eth_ipv6,             ICE_FDIR_INSET_ETH_IPV6,              ICE_INSET_NONE},
-	{pattern_eth_ipv6_udp,         ICE_FDIR_INSET_ETH_IPV6_UDP,          ICE_INSET_NONE},
-	{pattern_eth_ipv6_tcp,         ICE_FDIR_INSET_ETH_IPV6_TCP,          ICE_INSET_NONE},
-	{pattern_eth_ipv6_sctp,        ICE_FDIR_INSET_ETH_IPV6_SCTP,         ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_ipv4,
-				       ICE_FDIR_INSET_VXLAN_IPV4,            ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_ipv4_udp,
-				       ICE_FDIR_INSET_VXLAN_IPV4_UDP,        ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_ipv4_tcp,
-				       ICE_FDIR_INSET_VXLAN_IPV4_TCP,        ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_ipv4_sctp,
-				       ICE_FDIR_INSET_VXLAN_IPV4_SCTP,       ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4,
-				       ICE_FDIR_INSET_VXLAN_IPV4,            ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_udp,
-				       ICE_FDIR_INSET_VXLAN_IPV4_UDP,        ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_tcp,
-				       ICE_FDIR_INSET_VXLAN_IPV4_TCP,        ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_sctp,
-				       ICE_FDIR_INSET_VXLAN_IPV4_SCTP,       ICE_INSET_NONE},
-};
-
-static struct ice_pattern_match_item ice_fdir_pattern_comms[] = {
+static struct ice_pattern_match_item ice_fdir_pattern_list[] = {
 	{pattern_ethertype,	       ICE_FDIR_INSET_ETH,		     ICE_INSET_NONE},
 	{pattern_eth_ipv4,             ICE_FDIR_INSET_ETH_IPV4,              ICE_INSET_NONE},
 	{pattern_eth_ipv4_udp,         ICE_FDIR_INSET_ETH_IPV4_UDP,          ICE_INSET_NONE},
@@ -143,8 +116,7 @@ static struct ice_pattern_match_item ice_fdir_pattern_comms[] = {
 	{pattern_eth_ipv6_gtpu_eh,     ICE_FDIR_INSET_IPV6_GTPU_EH,          ICE_INSET_NONE},
 };
 
-static struct ice_flow_parser ice_fdir_parser_os;
-static struct ice_flow_parser ice_fdir_parser_comms;
+static struct ice_flow_parser ice_fdir_parser;
 
 static int
 ice_fdir_is_tunnel_profile(enum ice_fdir_tunnel_type tunnel_type);
@@ -1111,12 +1083,7 @@ ice_fdir_init(struct ice_adapter *ad)
 	if (ret)
 		return ret;
 
-	if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
-		parser = &ice_fdir_parser_comms;
-	else if (ad->active_pkg_type == ICE_PKG_TYPE_OS_DEFAULT)
-		parser = &ice_fdir_parser_os;
-	else
-		return -EINVAL;
+	parser = &ice_fdir_parser;
 
 	return ice_register_parser(parser, ad);
 }
@@ -1124,16 +1091,13 @@ ice_fdir_init(struct ice_adapter *ad)
 static void
 ice_fdir_uninit(struct ice_adapter *ad)
 {
-	struct ice_pf *pf = &ad->pf;
 	struct ice_flow_parser *parser;
+	struct ice_pf *pf = &ad->pf;
 
 	if (ad->hw.dcf_enabled)
 		return;
 
-	if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
-		parser = &ice_fdir_parser_comms;
-	else
-		parser = &ice_fdir_parser_os;
+	parser = &ice_fdir_parser;
 
 	ice_unregister_parser(parser, ad);
 
@@ -2039,7 +2003,8 @@ ice_fdir_parse(struct ice_adapter *ad,
 	int ret;
 
 	memset(filter, 0, sizeof(*filter));
-	item = ice_search_pattern_match_item(pattern, array, array_len, error);
+	item = ice_search_pattern_match_item(ad, pattern, array, array_len,
+					     error);
 	if (!item)
 		return -rte_errno;
 
@@ -2067,18 +2032,10 @@ ice_fdir_parse(struct ice_adapter *ad,
 	return ret;
 }
 
-static struct ice_flow_parser ice_fdir_parser_os = {
-	.engine = &ice_fdir_engine,
-	.array = ice_fdir_pattern_os,
-	.array_len = RTE_DIM(ice_fdir_pattern_os),
-	.parse_pattern_action = ice_fdir_parse,
-	.stage = ICE_FLOW_STAGE_DISTRIBUTOR,
-};
-
-static struct ice_flow_parser ice_fdir_parser_comms = {
+static struct ice_flow_parser ice_fdir_parser = {
 	.engine = &ice_fdir_engine,
-	.array = ice_fdir_pattern_comms,
-	.array_len = RTE_DIM(ice_fdir_pattern_comms),
+	.array = ice_fdir_pattern_list,
+	.array_len = RTE_DIM(ice_fdir_pattern_list),
 	.parse_pattern_action = ice_fdir_parse,
 	.stage = ICE_FLOW_STAGE_DISTRIBUTOR,
 };
diff --git a/drivers/net/ice/ice_generic_flow.c b/drivers/net/ice/ice_generic_flow.c
index 1429cbc3b6..4313aae183 100644
--- a/drivers/net/ice/ice_generic_flow.c
+++ b/drivers/net/ice/ice_generic_flow.c
@@ -2046,17 +2046,127 @@ ice_match_pattern(enum rte_flow_item_type *item_array,
 		item->type == RTE_FLOW_ITEM_TYPE_END);
 }
 
+struct ice_ptype_match {
+	enum rte_flow_item_type *pattern_list;
+	uint16_t hw_ptype;
+};
+
+static struct ice_ptype_match ice_ptype_map[] = {
+	{pattern_eth_ipv4,				ICE_PTYPE_IPV4_PAY},
+	{pattern_eth_ipv4_udp,				ICE_PTYPE_IPV4_UDP_PAY},
+	{pattern_eth_ipv4_tcp,				ICE_PTYPE_IPV4_TCP_PAY},
+	{pattern_eth_ipv4_sctp,				ICE_PTYPE_IPV4_SCTP_PAY},
+	{pattern_eth_ipv4_gtpu,				ICE_MAC_IPV4_GTPU},
+	{pattern_eth_ipv4_gtpu_eh,			ICE_MAC_IPV4_GTPU},
+	{pattern_eth_ipv4_gtpu_ipv4,			ICE_MAC_IPV4_GTPU_IPV4_PAY},
+	{pattern_eth_ipv4_gtpu_ipv4_udp,		ICE_MAC_IPV4_GTPU_IPV4_UDP_PAY},
+	{pattern_eth_ipv4_gtpu_ipv4_tcp,		ICE_MAC_IPV4_GTPU_IPV4_TCP},
+	{pattern_eth_ipv4_gtpu_ipv6,			ICE_MAC_IPV4_GTPU_IPV6_PAY},
+	{pattern_eth_ipv4_gtpu_ipv6_udp,		ICE_MAC_IPV4_GTPU_IPV6_UDP_PAY},
+	{pattern_eth_ipv4_gtpu_ipv6_tcp,		ICE_MAC_IPV4_GTPU_IPV6_TCP},
+	{pattern_eth_ipv4_gtpu_eh_ipv4,			ICE_MAC_IPV4_GTPU_IPV4_PAY},
+	{pattern_eth_ipv4_gtpu_eh_ipv4_udp,		ICE_MAC_IPV4_GTPU_IPV4_UDP_PAY},
+	{pattern_eth_ipv4_gtpu_eh_ipv4_tcp,		ICE_MAC_IPV4_GTPU_IPV4_TCP},
+	{pattern_eth_ipv4_gtpu_eh_ipv6,			ICE_MAC_IPV4_GTPU_IPV6_PAY},
+	{pattern_eth_ipv4_gtpu_eh_ipv6_udp,		ICE_MAC_IPV4_GTPU_IPV6_UDP_PAY},
+	{pattern_eth_ipv4_gtpu_eh_ipv6_tcp,		ICE_MAC_IPV4_GTPU_IPV6_TCP},
+	{pattern_eth_ipv4_esp,				ICE_MAC_IPV4_ESP},
+	{pattern_eth_ipv4_udp_esp,			ICE_MAC_IPV4_NAT_T_ESP},
+	{pattern_eth_ipv4_ah,				ICE_MAC_IPV4_AH},
+	{pattern_eth_ipv4_l2tp,				ICE_MAC_IPV4_L2TPV3},
+	{pattern_eth_ipv4_pfcp,				ICE_MAC_IPV4_PFCP_SESSION},
+	{pattern_eth_ipv6,				ICE_PTYPE_IPV6_PAY},
+	{pattern_eth_ipv6_udp,				ICE_PTYPE_IPV6_UDP_PAY},
+	{pattern_eth_ipv6_tcp,				ICE_PTYPE_IPV6_TCP_PAY},
+	{pattern_eth_ipv6_sctp,				ICE_PTYPE_IPV6_SCTP_PAY},
+	{pattern_eth_ipv6_gtpu,				ICE_MAC_IPV6_GTPU},
+	{pattern_eth_ipv6_gtpu_eh,			ICE_MAC_IPV6_GTPU},
+	{pattern_eth_ipv6_gtpu_ipv4,			ICE_MAC_IPV6_GTPU_IPV4_PAY},
+	{pattern_eth_ipv6_gtpu_ipv4_udp,		ICE_MAC_IPV6_GTPU_IPV4_UDP_PAY},
+	{pattern_eth_ipv6_gtpu_ipv4_tcp,		ICE_MAC_IPV6_GTPU_IPV4_TCP},
+	{pattern_eth_ipv6_gtpu_ipv6,			ICE_MAC_IPV6_GTPU_IPV6_PAY},
+	{pattern_eth_ipv6_gtpu_ipv6_udp,		ICE_MAC_IPV6_GTPU_IPV6_UDP_PAY},
+	{pattern_eth_ipv6_gtpu_ipv6_tcp,		ICE_MAC_IPV6_GTPU_IPV6_TCP},
+	{pattern_eth_ipv6_gtpu_eh_ipv4,			ICE_MAC_IPV6_GTPU_IPV4_PAY},
+	{pattern_eth_ipv6_gtpu_eh_ipv4_udp,		ICE_MAC_IPV6_GTPU_IPV4_UDP_PAY},
+	{pattern_eth_ipv6_gtpu_eh_ipv4_tcp,		ICE_MAC_IPV6_GTPU_IPV4_TCP},
+	{pattern_eth_ipv6_gtpu_eh_ipv6,			ICE_MAC_IPV6_GTPU_IPV6_PAY},
+	{pattern_eth_ipv6_gtpu_eh_ipv6_udp,		ICE_MAC_IPV6_GTPU_IPV6_UDP_PAY},
+	{pattern_eth_ipv6_gtpu_eh_ipv6_tcp,		ICE_MAC_IPV6_GTPU_IPV6_TCP},
+	{pattern_eth_ipv6_esp,				ICE_MAC_IPV6_ESP},
+	{pattern_eth_ipv6_udp_esp,			ICE_MAC_IPV6_NAT_T_ESP},
+	{pattern_eth_ipv6_ah,				ICE_MAC_IPV6_AH},
+	{pattern_eth_ipv6_l2tp,				ICE_MAC_IPV6_L2TPV3},
+	{pattern_eth_ipv6_pfcp,				ICE_MAC_IPV6_PFCP_SESSION},
+	{pattern_ethertype,				ICE_PTYPE_MAC_PAY},
+	{pattern_ethertype_vlan,			ICE_PTYPE_MAC_PAY},
+	{pattern_eth_arp,				ICE_PTYPE_MAC_PAY},
+	{pattern_eth_vlan_ipv4,				ICE_PTYPE_IPV4_PAY},
+	{pattern_eth_vlan_ipv4_udp,			ICE_PTYPE_IPV4_UDP_PAY},
+	{pattern_eth_vlan_ipv4_tcp,			ICE_PTYPE_IPV4_TCP_PAY},
+	{pattern_eth_vlan_ipv4_sctp,			ICE_PTYPE_IPV4_SCTP_PAY},
+	{pattern_eth_vlan_ipv6,				ICE_PTYPE_IPV6_PAY},
+	{pattern_eth_vlan_ipv6_udp,			ICE_PTYPE_IPV6_UDP_PAY},
+	{pattern_eth_vlan_ipv6_tcp,			ICE_PTYPE_IPV6_TCP_PAY},
+	{pattern_eth_vlan_ipv6_sctp,			ICE_PTYPE_IPV6_SCTP_PAY},
+	{pattern_eth_pppoes,				ICE_MAC_PPPOE_PAY},
+	{pattern_eth_vlan_pppoes,			ICE_MAC_PPPOE_PAY},
+	{pattern_eth_pppoes_proto,			ICE_MAC_PPPOE_PAY},
+	{pattern_eth_vlan_pppoes_proto,			ICE_MAC_PPPOE_PAY},
+	{pattern_eth_pppoes_ipv4,			ICE_MAC_PPPOE_IPV4_PAY},
+	{pattern_eth_pppoes_ipv4_udp,			ICE_MAC_PPPOE_IPV4_UDP_PAY},
+	{pattern_eth_pppoes_ipv4_tcp,			ICE_MAC_PPPOE_IPV4_TCP},
+	{pattern_eth_vlan_pppoes_ipv4,			ICE_MAC_PPPOE_IPV4_PAY},
+	{pattern_eth_vlan_pppoes_ipv4_tcp,		ICE_MAC_PPPOE_IPV4_TCP},
+	{pattern_eth_vlan_pppoes_ipv4_udp,		ICE_MAC_PPPOE_IPV4_UDP_PAY},
+	{pattern_eth_pppoes_ipv6,			ICE_MAC_PPPOE_IPV6_PAY},
+	{pattern_eth_pppoes_ipv6_udp,			ICE_MAC_PPPOE_IPV6_UDP_PAY},
+	{pattern_eth_pppoes_ipv6_tcp,			ICE_MAC_PPPOE_IPV6_TCP},
+	{pattern_eth_vlan_pppoes_ipv6,			ICE_MAC_PPPOE_IPV6_PAY},
+	{pattern_eth_vlan_pppoes_ipv6_tcp,		ICE_MAC_PPPOE_IPV6_TCP},
+	{pattern_eth_vlan_pppoes_ipv6_udp,		ICE_MAC_PPPOE_IPV6_UDP_PAY},
+	{pattern_eth_ipv4_udp_vxlan_ipv4,		ICE_MAC_IPV4_TUN_IPV4_PAY},
+	{pattern_eth_ipv4_udp_vxlan_ipv4_udp,		ICE_MAC_IPV4_TUN_IPV4_UDP_PAY},
+	{pattern_eth_ipv4_udp_vxlan_ipv4_tcp,		ICE_MAC_IPV4_TUN_IPV4_TCP},
+	{pattern_eth_ipv4_udp_vxlan_ipv4_sctp,		ICE_MAC_IPV4_TUN_IPV4_SCTP},
+	{pattern_eth_ipv4_udp_vxlan_eth_ipv4,		ICE_MAC_IPV4_TUN_IPV4_PAY},
+	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_udp,	ICE_MAC_IPV4_TUN_IPV4_UDP_PAY},
+	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_tcp,	ICE_MAC_IPV4_TUN_IPV4_TCP},
+	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_sctp,	ICE_MAC_IPV4_TUN_IPV4_SCTP},
+	{pattern_eth_ipv4_nvgre_eth_ipv4,		ICE_MAC_IPV4_TUN_IPV4_PAY},
+	{pattern_eth_ipv4_nvgre_eth_ipv4_udp,		ICE_MAC_IPV4_TUN_IPV4_UDP_PAY},
+	{pattern_eth_ipv4_nvgre_eth_ipv4_tcp,		ICE_MAC_IPV4_TUN_IPV4_TCP},
+};
+
+static bool
+ice_pattern_is_supported(__rte_unused struct ice_adapter *ad,
+			 const struct rte_flow_item *pattern)
+{
+	uint16_t i;
+
+	for (i = 0; i < RTE_DIM(ice_ptype_map); i++) {
+		if (ice_match_pattern(ice_ptype_map[i].pattern_list,
+				      pattern)) {
+			return ice_hw_ptype_ena(&ad->hw,
+						ice_ptype_map[i].hw_ptype);
+		}
+	}
+
+	return false;
+}
+
 struct ice_pattern_match_item *
-ice_search_pattern_match_item(const struct rte_flow_item pattern[],
-		struct ice_pattern_match_item *array,
-		uint32_t array_len,
-		struct rte_flow_error *error)
+ice_search_pattern_match_item(struct ice_adapter *ad,
+			      const struct rte_flow_item pattern[],
+			      struct ice_pattern_match_item *array,
+			      uint32_t array_len,
+			      struct rte_flow_error *error)
 {
-	uint16_t i = 0;
 	struct ice_pattern_match_item *pattern_match_item;
 	/* need free by each filter */
 	struct rte_flow_item *items; /* used for pattern without VOID items */
 	uint32_t item_num = 0; /* non-void item number */
+	uint16_t i = 0;
 
 	/* Get the non-void item number of pattern */
 	while ((pattern + i)->type != RTE_FLOW_ITEM_TYPE_END) {
@@ -2078,14 +2188,18 @@ ice_search_pattern_match_item(const struct rte_flow_item pattern[],
 	if (!pattern_match_item) {
 		rte_flow_error_set(error, ENOMEM, RTE_FLOW_ERROR_TYPE_HANDLE,
 				NULL, "Failed to allocate memory.");
+		rte_free(items);
 		return NULL;
 	}
 
 	ice_pattern_skip_void_item(items, pattern);
 
-	for (i = 0; i < array_len; i++)
+	if (!ice_pattern_is_supported(ad, pattern))
+		goto unsupported;
+
+	for (i = 0; i < array_len; i++) {
 		if (ice_match_pattern(array[i].pattern_list,
-					items)) {
+				      items)) {
 			pattern_match_item->input_set_mask =
 				array[i].input_set_mask;
 			pattern_match_item->pattern_list =
@@ -2094,9 +2208,11 @@ ice_search_pattern_match_item(const struct rte_flow_item pattern[],
 			rte_free(items);
 			return pattern_match_item;
 		}
+	}
+
+unsupported:
 	rte_flow_error_set(error, EINVAL, RTE_FLOW_ERROR_TYPE_ITEM,
 			   pattern, "Unsupported pattern");
-
 	rte_free(items);
 	rte_free(pattern_match_item);
 	return NULL;
diff --git a/drivers/net/ice/ice_generic_flow.h b/drivers/net/ice/ice_generic_flow.h
index 434d2f425d..0dcb620809 100644
--- a/drivers/net/ice/ice_generic_flow.h
+++ b/drivers/net/ice/ice_generic_flow.h
@@ -593,10 +593,11 @@ int ice_register_parser(struct ice_flow_parser *parser,
 void ice_unregister_parser(struct ice_flow_parser *parser,
 		struct ice_adapter *ad);
 struct ice_pattern_match_item *
-ice_search_pattern_match_item(const struct rte_flow_item pattern[],
-		struct ice_pattern_match_item *array,
-		uint32_t array_len,
-		struct rte_flow_error *error);
+ice_search_pattern_match_item(struct ice_adapter *ad,
+			      const struct rte_flow_item pattern[],
+			      struct ice_pattern_match_item *array,
+			      uint32_t array_len,
+			      struct rte_flow_error *error);
 int
 ice_flow_redirect(struct ice_adapter *ad,
 		  struct ice_flow_redirect *rd);
diff --git a/drivers/net/ice/ice_hash.c b/drivers/net/ice/ice_hash.c
index fe3e06c579..fab2d397b7 100644
--- a/drivers/net/ice/ice_hash.c
+++ b/drivers/net/ice/ice_hash.c
@@ -313,21 +313,7 @@ struct rss_type_match_hdr hint_eth_pppoes = {
 	ICE_FLOW_SEG_HDR_PPPOE,
 	ETH_RSS_ETH | ETH_RSS_PPPOE};
 
-/* Supported pattern for os default package. */
-static struct ice_pattern_match_item ice_hash_pattern_list_os[] = {
-	{pattern_eth_ipv4,	ICE_INSET_NONE,	&hint_eth_ipv4},
-	{pattern_eth_ipv4_udp,	ICE_INSET_NONE,	&hint_eth_ipv4_udp},
-	{pattern_eth_ipv4_tcp,	ICE_INSET_NONE,	&hint_eth_ipv4_tcp},
-	{pattern_eth_ipv4_sctp,	ICE_INSET_NONE,	&hint_eth_ipv4_sctp},
-	{pattern_eth_ipv6,	ICE_INSET_NONE,	&hint_eth_ipv6},
-	{pattern_eth_ipv6_udp,	ICE_INSET_NONE,	&hint_eth_ipv6_udp},
-	{pattern_eth_ipv6_tcp,	ICE_INSET_NONE,	&hint_eth_ipv6_tcp},
-	{pattern_eth_ipv6_sctp,	ICE_INSET_NONE,	&hint_eth_ipv6_sctp},
-	{pattern_empty,		ICE_INSET_NONE,	&hint_empty},
-};
-
-/* Supported pattern for comms package. */
-static struct ice_pattern_match_item ice_hash_pattern_list_comms[] = {
+static struct ice_pattern_match_item ice_hash_pattern_list[] = {
 	{pattern_empty,			    ICE_INSET_NONE,
 		&hint_empty},
 	{pattern_eth_ipv4,		    ICE_INSET_NONE,
@@ -915,19 +901,10 @@ static struct ice_flow_engine ice_hash_engine = {
 };
 
 /* Register parser for os package. */
-static struct ice_flow_parser ice_hash_parser_os = {
-	.engine = &ice_hash_engine,
-	.array = ice_hash_pattern_list_os,
-	.array_len = RTE_DIM(ice_hash_pattern_list_os),
-	.parse_pattern_action = ice_hash_parse_pattern_action,
-	.stage = ICE_FLOW_STAGE_RSS,
-};
-
-/* Register parser for comms package. */
-static struct ice_flow_parser ice_hash_parser_comms = {
+static struct ice_flow_parser ice_hash_parser = {
 	.engine = &ice_hash_engine,
-	.array = ice_hash_pattern_list_comms,
-	.array_len = RTE_DIM(ice_hash_pattern_list_comms),
+	.array = ice_hash_pattern_list,
+	.array_len = RTE_DIM(ice_hash_pattern_list),
 	.parse_pattern_action = ice_hash_parse_pattern_action,
 	.stage = ICE_FLOW_STAGE_RSS,
 };
@@ -946,12 +923,7 @@ ice_hash_init(struct ice_adapter *ad)
 	if (ad->hw.dcf_enabled)
 		return 0;
 
-	if (ad->active_pkg_type == ICE_PKG_TYPE_OS_DEFAULT)
-		parser = &ice_hash_parser_os;
-	else if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
-		parser = &ice_hash_parser_comms;
-	else
-		return -EINVAL;
+	parser = &ice_hash_parser;
 
 	return ice_register_parser(parser, ad);
 }
@@ -1211,8 +1183,8 @@ ice_hash_parse_pattern_action(__rte_unused struct ice_adapter *ad,
 	}
 
 	/* Check rss supported pattern and find matched pattern. */
-	pattern_match_item = ice_search_pattern_match_item(pattern,
-					array, array_len, error);
+	pattern_match_item = ice_search_pattern_match_item(ad, pattern, array,
+							   array_len, error);
 	if (!pattern_match_item) {
 		ret = -rte_errno;
 		goto error;
@@ -1352,10 +1324,7 @@ ice_hash_uninit(struct ice_adapter *ad)
 	if (ad->hw.dcf_enabled)
 		return;
 
-	if (ad->active_pkg_type == ICE_PKG_TYPE_OS_DEFAULT)
-		ice_unregister_parser(&ice_hash_parser_os, ad);
-	else if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
-		ice_unregister_parser(&ice_hash_parser_comms, ad);
+	ice_unregister_parser(&ice_hash_parser, ad);
 }
 
 static void
diff --git a/drivers/net/ice/ice_switch_filter.c b/drivers/net/ice/ice_switch_filter.c
index 8cba6eb7b1..e5b7d56068 100644
--- a/drivers/net/ice/ice_switch_filter.c
+++ b/drivers/net/ice/ice_switch_filter.c
@@ -137,47 +137,11 @@ struct sw_meta {
 	struct ice_adv_rule_info rule_info;
 };
 
-static struct ice_flow_parser ice_switch_dist_parser_os;
-static struct ice_flow_parser ice_switch_dist_parser_comms;
-static struct ice_flow_parser ice_switch_perm_parser_os;
-static struct ice_flow_parser ice_switch_perm_parser_comms;
+static struct ice_flow_parser ice_switch_dist_parser;
+static struct ice_flow_parser ice_switch_perm_parser;
 
 static struct
-ice_pattern_match_item ice_switch_pattern_dist_os[] = {
-	{pattern_ethertype,
-			ICE_SW_INSET_ETHER, ICE_INSET_NONE},
-	{pattern_ethertype_vlan,
-			ICE_SW_INSET_MAC_VLAN, ICE_INSET_NONE},
-	{pattern_eth_arp,
-			ICE_INSET_NONE, ICE_INSET_NONE},
-	{pattern_eth_ipv4,
-			ICE_SW_INSET_MAC_IPV4, ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp,
-			ICE_SW_INSET_MAC_IPV4_UDP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_tcp,
-			ICE_SW_INSET_MAC_IPV4_TCP, ICE_INSET_NONE},
-	{pattern_eth_ipv6,
-			ICE_SW_INSET_MAC_IPV6, ICE_INSET_NONE},
-	{pattern_eth_ipv6_udp,
-			ICE_SW_INSET_MAC_IPV6_UDP, ICE_INSET_NONE},
-	{pattern_eth_ipv6_tcp,
-			ICE_SW_INSET_MAC_IPV6_TCP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4,
-			ICE_SW_INSET_DIST_VXLAN_IPV4, ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_udp,
-			ICE_SW_INSET_DIST_VXLAN_IPV4_UDP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_tcp,
-			ICE_SW_INSET_DIST_VXLAN_IPV4_TCP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_nvgre_eth_ipv4,
-			ICE_SW_INSET_DIST_NVGRE_IPV4, ICE_INSET_NONE},
-	{pattern_eth_ipv4_nvgre_eth_ipv4_udp,
-			ICE_SW_INSET_DIST_NVGRE_IPV4_UDP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_nvgre_eth_ipv4_tcp,
-			ICE_SW_INSET_DIST_NVGRE_IPV4_TCP, ICE_INSET_NONE},
-};
-
-static struct
-ice_pattern_match_item ice_switch_pattern_dist_comms[] = {
+ice_pattern_match_item ice_switch_pattern_dist_list[] = {
 	{pattern_ethertype,
 			ICE_SW_INSET_ETHER, ICE_INSET_NONE},
 	{pattern_ethertype_vlan,
@@ -265,41 +229,7 @@ ice_pattern_match_item ice_switch_pattern_dist_comms[] = {
 };
 
 static struct
-ice_pattern_match_item ice_switch_pattern_perm_os[] = {
-	{pattern_ethertype,
-			ICE_SW_INSET_ETHER, ICE_INSET_NONE},
-	{pattern_ethertype_vlan,
-			ICE_SW_INSET_MAC_VLAN, ICE_INSET_NONE},
-	{pattern_eth_arp,
-			ICE_INSET_NONE, ICE_INSET_NONE},
-	{pattern_eth_ipv4,
-			ICE_SW_INSET_MAC_IPV4, ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp,
-			ICE_SW_INSET_MAC_IPV4_UDP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_tcp,
-			ICE_SW_INSET_MAC_IPV4_TCP, ICE_INSET_NONE},
-	{pattern_eth_ipv6,
-			ICE_SW_INSET_MAC_IPV6, ICE_INSET_NONE},
-	{pattern_eth_ipv6_udp,
-			ICE_SW_INSET_MAC_IPV6_UDP, ICE_INSET_NONE},
-	{pattern_eth_ipv6_tcp,
-			ICE_SW_INSET_MAC_IPV6_TCP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4,
-			ICE_SW_INSET_PERM_TUNNEL_IPV4, ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_udp,
-			ICE_SW_INSET_PERM_TUNNEL_IPV4_UDP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_tcp,
-			ICE_SW_INSET_PERM_TUNNEL_IPV4_TCP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_nvgre_eth_ipv4,
-			ICE_SW_INSET_PERM_TUNNEL_IPV4, ICE_INSET_NONE},
-	{pattern_eth_ipv4_nvgre_eth_ipv4_udp,
-			ICE_SW_INSET_PERM_TUNNEL_IPV4_UDP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_nvgre_eth_ipv4_tcp,
-			ICE_SW_INSET_PERM_TUNNEL_IPV4_TCP, ICE_INSET_NONE},
-};
-
-static struct
-ice_pattern_match_item ice_switch_pattern_perm_comms[] = {
+ice_pattern_match_item ice_switch_pattern_perm_list[] = {
 	{pattern_ethertype,
 			ICE_SW_INSET_ETHER, ICE_INSET_NONE},
 	{pattern_ethertype_vlan,
@@ -1699,7 +1629,8 @@ ice_switch_parse_pattern_action(struct ice_adapter *ad,
 	}
 
 	pattern_match_item =
-		ice_search_pattern_match_item(pattern, array, array_len, error);
+		ice_search_pattern_match_item(ad, pattern, array, array_len,
+					      error);
 	if (!pattern_match_item) {
 		rte_flow_error_set(error, EINVAL,
 				   RTE_FLOW_ERROR_TYPE_HANDLE, NULL,
@@ -1859,21 +1790,11 @@ ice_switch_init(struct ice_adapter *ad)
 	struct ice_flow_parser *dist_parser;
 	struct ice_flow_parser *perm_parser;
 
-	if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
-		dist_parser = &ice_switch_dist_parser_comms;
-	else if (ad->active_pkg_type == ICE_PKG_TYPE_OS_DEFAULT)
-		dist_parser = &ice_switch_dist_parser_os;
-	else
-		return -EINVAL;
-
 	if (ad->devargs.pipe_mode_support) {
-		if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
-			perm_parser = &ice_switch_perm_parser_comms;
-		else
-			perm_parser = &ice_switch_perm_parser_os;
-
+		perm_parser = &ice_switch_perm_parser;
 		ret = ice_register_parser(perm_parser, ad);
 	} else {
+		dist_parser = &ice_switch_dist_parser;
 		ret = ice_register_parser(dist_parser, ad);
 	}
 	return ret;
@@ -1885,21 +1806,11 @@ ice_switch_uninit(struct ice_adapter *ad)
 	struct ice_flow_parser *dist_parser;
 	struct ice_flow_parser *perm_parser;
 
-	if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
-		dist_parser = &ice_switch_dist_parser_comms;
-	else if (ad->active_pkg_type == ICE_PKG_TYPE_OS_DEFAULT)
-		dist_parser = &ice_switch_dist_parser_os;
-	else
-		return;
-
 	if (ad->devargs.pipe_mode_support) {
-		if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
-			perm_parser = &ice_switch_perm_parser_comms;
-		else
-			perm_parser = &ice_switch_perm_parser_os;
-
+		perm_parser = &ice_switch_perm_parser;
 		ice_unregister_parser(perm_parser, ad);
 	} else {
+		dist_parser = &ice_switch_dist_parser;
 		ice_unregister_parser(dist_parser, ad);
 	}
 }
@@ -1917,37 +1828,19 @@ ice_flow_engine ice_switch_engine = {
 };
 
 static struct
-ice_flow_parser ice_switch_dist_parser_os = {
+ice_flow_parser ice_switch_dist_parser = {
 	.engine = &ice_switch_engine,
-	.array = ice_switch_pattern_dist_os,
-	.array_len = RTE_DIM(ice_switch_pattern_dist_os),
+	.array = ice_switch_pattern_dist_list,
+	.array_len = RTE_DIM(ice_switch_pattern_dist_list),
 	.parse_pattern_action = ice_switch_parse_pattern_action,
 	.stage = ICE_FLOW_STAGE_DISTRIBUTOR,
 };
 
 static struct
-ice_flow_parser ice_switch_dist_parser_comms = {
-	.engine = &ice_switch_engine,
-	.array = ice_switch_pattern_dist_comms,
-	.array_len = RTE_DIM(ice_switch_pattern_dist_comms),
-	.parse_pattern_action = ice_switch_parse_pattern_action,
-	.stage = ICE_FLOW_STAGE_DISTRIBUTOR,
-};
-
-static struct
-ice_flow_parser ice_switch_perm_parser_os = {
-	.engine = &ice_switch_engine,
-	.array = ice_switch_pattern_perm_os,
-	.array_len = RTE_DIM(ice_switch_pattern_perm_os),
-	.parse_pattern_action = ice_switch_parse_pattern_action,
-	.stage = ICE_FLOW_STAGE_PERMISSION,
-};
-
-static struct
-ice_flow_parser ice_switch_perm_parser_comms = {
+ice_flow_parser ice_switch_perm_parser = {
 	.engine = &ice_switch_engine,
-	.array = ice_switch_pattern_perm_comms,
-	.array_len = RTE_DIM(ice_switch_pattern_perm_comms),
+	.array = ice_switch_pattern_perm_list,
+	.array_len = RTE_DIM(ice_switch_pattern_perm_list),
 	.parse_pattern_action = ice_switch_parse_pattern_action,
 	.stage = ICE_FLOW_STAGE_PERMISSION,
 };
-- 
2.20.1

[dpdk-dev] [dpdk-dev v4 0/2] net/ice: refactor PTYPE parsing

[Jeff Guo]

If the capability of a PTYPE within a specific package could be
negotiated, no need to maintain a different PTYPE list for each
type of the package when parsing PTYPE. So refactor the PTYPE
parsing mechanism for each flow engines.

v4:
rebase patch and add some more PTYPE macros

v3:
separate the patch set from the ecpri configure patch set

Jeff Guo (2):
  net/ice/base: add PTYPE value
  net/ice: refactor PTYPE parsing

 drivers/net/ice/base/ice_flex_type.h | 189 +++++++++++++++++++++------
 drivers/net/ice/ice_acl_filter.c     |   3 +-
 drivers/net/ice/ice_fdir_filter.c    |  63 ++-------
 drivers/net/ice/ice_generic_flow.c   | 132 +++++++++++++++++--
 drivers/net/ice/ice_generic_flow.h   |   9 +-
 drivers/net/ice/ice_hash.c           |  51 ++------
 drivers/net/ice/ice_switch_filter.c  | 139 +++-----------------
 7 files changed, 315 insertions(+), 271 deletions(-)

-- 
2.20.1

[dpdk-dev] [dpdk-dev v4 1/2] net/ice/base: add PTYPE value

[Jeff Guo]

Add some macros for some PType value.

Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
 drivers/net/ice/base/ice_flex_type.h | 189 +++++++++++++++++++++------
 1 file changed, 150 insertions(+), 39 deletions(-)

diff --git a/drivers/net/ice/base/ice_flex_type.h b/drivers/net/ice/base/ice_flex_type.h
index ad620f7892..c7f92b9150 100644
--- a/drivers/net/ice/base/ice_flex_type.h
+++ b/drivers/net/ice/base/ice_flex_type.h
@@ -267,45 +267,156 @@ enum ice_sect {
 };
 
 /* Packet Type (PTYPE) values */
-#define ICE_PTYPE_MAC_PAY		1
-#define ICE_PTYPE_IPV4FRAG_PAY		22
-#define ICE_PTYPE_IPV4_PAY		23
-#define ICE_PTYPE_IPV4_UDP_PAY		24
-#define ICE_PTYPE_IPV4_TCP_PAY		26
-#define ICE_PTYPE_IPV4_SCTP_PAY		27
-#define ICE_PTYPE_IPV4_ICMP_PAY		28
-#define ICE_PTYPE_IPV6FRAG_PAY		88
-#define ICE_PTYPE_IPV6_PAY		89
-#define ICE_PTYPE_IPV6_UDP_PAY		90
-#define ICE_PTYPE_IPV6_TCP_PAY		92
-#define ICE_PTYPE_IPV6_SCTP_PAY		93
-#define ICE_PTYPE_IPV6_ICMP_PAY		94
-#define ICE_MAC_IPV4_GTPC_TEID		325
-#define ICE_MAC_IPV6_GTPC_TEID		326
-#define ICE_MAC_IPV4_GTPC		327
-#define ICE_MAC_IPV6_GTPC		328
-#define ICE_MAC_IPV4_GTPU		329
-#define ICE_MAC_IPV6_GTPU		330
-#define ICE_MAC_IPV4_GTPU_IPV4_FRAG	331
-#define ICE_MAC_IPV4_GTPU_IPV4_PAY	332
-#define ICE_MAC_IPV4_GTPU_IPV4_UDP_PAY	333
-#define ICE_MAC_IPV4_GTPU_IPV4_TCP	334
-#define ICE_MAC_IPV4_GTPU_IPV4_ICMP	335
-#define ICE_MAC_IPV6_GTPU_IPV4_FRAG	336
-#define ICE_MAC_IPV6_GTPU_IPV4_PAY	337
-#define ICE_MAC_IPV6_GTPU_IPV4_UDP_PAY	338
-#define ICE_MAC_IPV6_GTPU_IPV4_TCP	339
-#define ICE_MAC_IPV6_GTPU_IPV4_ICMP	340
-#define ICE_MAC_IPV4_GTPU_IPV6_FRAG	341
-#define ICE_MAC_IPV4_GTPU_IPV6_PAY	342
-#define ICE_MAC_IPV4_GTPU_IPV6_UDP_PAY	343
-#define ICE_MAC_IPV4_GTPU_IPV6_TCP	344
-#define ICE_MAC_IPV4_GTPU_IPV6_ICMPV6	345
-#define ICE_MAC_IPV6_GTPU_IPV6_FRAG	346
-#define ICE_MAC_IPV6_GTPU_IPV6_PAY	347
-#define ICE_MAC_IPV6_GTPU_IPV6_UDP_PAY	348
-#define ICE_MAC_IPV6_GTPU_IPV6_TCP	349
-#define ICE_MAC_IPV6_GTPU_IPV6_ICMPV6	350
+#define ICE_PTYPE_MAC_PAY			1
+#define ICE_MAC_PTP				2
+#define ICE_MAC_LLDP				6
+#define ICE_MAC_ARP				11
+#define ICE_PTYPE_IPV4FRAG_PAY			22
+#define ICE_PTYPE_IPV4_PAY			23
+#define ICE_PTYPE_IPV4_UDP_PAY			24
+#define ICE_PTYPE_IPV4_TCP_PAY			26
+#define ICE_PTYPE_IPV4_SCTP_PAY			27
+#define ICE_PTYPE_IPV4_ICMP_PAY			28
+#define ICE_MAC_IPV4_IPV4_FRAG			29
+#define ICE_MAC_IPV4_IPV4_PAY			30
+#define ICE_MAC_IPV4_IPV4_UDP_PAY		31
+#define ICE_MAC_IPV4_IPV4_TCP			33
+#define ICE_MAC_IPV4_IPV4_SCTP			34
+#define ICE_MAC_IPV4_IPV4_ICMP			35
+#define ICE_MAC_IPV4_IPV6_FRAG			36
+#define ICE_MAC_IPV4_IPV6_PAY			37
+#define ICE_MAC_IPV4_IPV6_UDP_PAY		38
+#define ICE_MAC_IPV4_IPV6_TCP			40
+#define ICE_MAC_IPV4_IPV6_SCTP			41
+#define ICE_MAC_IPV4_IPV6_ICMPV6		42
+#define ICE_MAC_IPV4_TUN_PAY			43
+#define ICE_MAC_IPV4_TUN_IPV4_FRAG		44
+#define ICE_MAC_IPV4_TUN_IPV4_PAY		45
+#define ICE_MAC_IPV4_TUN_IPV4_UDP_PAY		46
+#define ICE_MAC_IPV4_TUN_IPV4_TCP		48
+#define ICE_MAC_IPV4_TUN_IPV4_SCTP		49
+#define ICE_MAC_IPV4_TUN_IPV4_ICMP		50
+#define ICE_MAC_IPV4_TUN_IPV6_FRAG		51
+#define ICE_MAC_IPV4_TUN_IPV6_PAY		52
+#define ICE_MAC_IPV4_TUN_IPV6_UDP_PAY		53
+#define ICE_MAC_IPV4_TUN_IPV6_TCP		55
+#define ICE_MAC_IPV4_TUN_IPV6_SCTP		56
+#define ICE_MAC_IPV4_TUN_IPV6_ICMPV6		57
+#define ICE_MAC_IPV4_TUN_ICE_MAC_PAY		58
+#define ICE_MAC_IPV4_TUN_ICE_MAC_IPV4_FRAG	59
+#define ICE_MAC_IPV4_TUN_ICE_MAC_IPV4_PAY	60
+#define ICE_MAC_IPV4_TUN_ICE_MAC_IPV4_UDP_PAY	61
+#define ICE_MAC_IPV4_TUN_ICE_MAC_IPV4_TCP	63
+#define ICE_MAC_IPV4_TUN_ICE_MAC_IPV4_SCTP	64
+#define ICE_MAC_IPV4_TUN_ICE_MAC_IPV4_ICMP	65
+#define ICE_MAC_IPV4_TUN_ICE_MAC_IPV6_FRAG	66
+#define ICE_MAC_IPV4_TUN_ICE_MAC_IPV6_PAY	67
+#define ICE_MAC_IPV4_TUN_ICE_MAC_IPV6_UDP_PAY	68
+#define ICE_MAC_IPV4_TUN_ICE_MAC_IPV6_TCP	70
+#define ICE_MAC_IPV4_TUN_ICE_MAC_IPV6_SCTP	71
+#define ICE_MAC_IPV4_TUN_ICE_MAC_IPV6_ICMPV6	72
+#define ICE_PTYPE_IPV6FRAG_PAY			88
+#define ICE_PTYPE_IPV6_PAY			89
+#define ICE_PTYPE_IPV6_UDP_PAY			90
+#define ICE_PTYPE_IPV6_TCP_PAY			92
+#define ICE_PTYPE_IPV6_SCTP_PAY			93
+#define ICE_PTYPE_IPV6_ICMP_PAY			94
+#define ICE_MAC_IPV6_IPV4_FRAG			95
+#define ICE_MAC_IPV6_IPV4_PAY			96
+#define ICE_MAC_IPV6_IPV4_UDP_PAY		97
+#define ICE_MAC_IPV6_IPV4_TCP			99
+#define ICE_MAC_IPV6_IPV4_SCTP			100
+#define ICE_MAC_IPV6_IPV4_ICMP			101
+#define ICE_MAC_IPV6_IPV6_FRAG			102
+#define ICE_MAC_IPV6_IPV6_PAY			103
+#define ICE_MAC_IPV6_IPV6_UDP_PAY		104
+#define ICE_MAC_IPV6_IPV6_TCP			106
+#define ICE_MAC_IPV6_IPV6_SCTP			107
+#define ICE_MAC_IPV6_IPV6_ICMPV6		108
+#define ICE_MAC_IPV6_TUN_PAY			109
+#define ICE_MAC_IPV6_TUN_IPV4_FRAG		110
+#define ICE_MAC_IPV6_TUN_IPV4_PAY		111
+#define ICE_MAC_IPV6_TUN_IPV4_UDP_PAY		112
+#define ICE_MAC_IPV6_TUN_IPV4_TCP		114
+#define ICE_MAC_IPV6_TUN_IPV4_SCTP		115
+#define ICE_MAC_IPV6_TUN_IPV4_ICMP		116
+#define ICE_MAC_IPV6_TUN_IPV6_FRAG		117
+#define ICE_MAC_IPV6_TUN_IPV6_PAY		118
+#define ICE_MAC_IPV6_TUN_IPV6_UDP_PAY		119
+#define ICE_MAC_IPV6_TUN_IPV6_TCP		121
+#define ICE_MAC_IPV6_TUN_IPV6_SCTP		122
+#define ICE_MAC_IPV6_TUN_IPV6_ICMPV6		123
+#define ICE_MAC_IPV6_TUN_MAC_PAY		124
+#define ICE_MAC_IPV6_TUN_MAC_IPV4_FRAG		125
+#define ICE_MAC_IPV6_TUN_MAC_IPV4_PAY		126
+#define ICE_MAC_IPV6_TUN_MAC_IPV4_UDP_PAY	127
+#define ICE_MAC_IPV6_TUN_MAC_IPV4_TCP		129
+#define ICE_MAC_IPV6_TUN_MAC_IPV4_SCTP		130
+#define ICE_MAC_IPV6_TUN_MAC_IPV4_ICMP		131
+#define ICE_MAC_IPV6_TUN_MAC_IPV6_FRAG		132
+#define ICE_MAC_IPV6_TUN_MAC_IPV6_PAY		133
+#define ICE_MAC_IPV6_TUN_MAC_IPV6_UDP_PAY	134
+#define ICE_MAC_IPV6_TUN_MAC_IPV6_TCP		136
+#define ICE_MAC_IPV6_TUN_MAC_IPV6_SCTP		137
+#define ICE_MAC_IPV6_TUN_MAC_IPV6_ICMPV6	138
+#define ICE_MAC_IPV4_ESP			160
+#define ICE_MAC_IPV6_ESP			161
+#define ICE_MAC_IPV4_AH				162
+#define ICE_MAC_IPV6_AH				163
+#define ICE_MAC_IPV4_NAT_T_ESP			164
+#define ICE_MAC_IPV6_NAT_T_ESP			165
+#define ICE_MAC_IPV4_NAT_T_IKE			166
+#define ICE_MAC_IPV6_NAT_T_IKE			167
+#define ICE_MAC_IPV4_NAT_T_KEEP			168
+#define ICE_MAC_IPV6_NAT_T_KEEP			169
+#define ICE_MAC_CONTROL				278
+#define ICE_MAC_PPPOD_PAY			300
+#define ICE_MAC_PPPOE_PAY			301
+#define ICE_MAC_PPPOE_IPV4_FRAG			302
+#define ICE_MAC_PPPOE_IPV4_PAY			303
+#define ICE_MAC_PPPOE_IPV4_UDP_PAY		304
+#define ICE_MAC_PPPOE_IPV4_TCP			305
+#define ICE_MAC_PPPOE_IPV4_SCTP			306
+#define ICE_MAC_PPPOE_IPV4_ICMP			307
+#define ICE_MAC_PPPOE_IPV6_FRAG			308
+#define ICE_MAC_PPPOE_IPV6_PAY			309
+#define ICE_MAC_PPPOE_IPV6_UDP_PAY		310
+#define ICE_MAC_PPPOE_IPV6_TCP			311
+#define ICE_MAC_PPPOE_IPV6_SCTP			312
+#define ICE_MAC_PPPOE_IPV6_ICMPV6		313
+#define ICE_MAC_IPV4_GTPC_TEID			325
+#define ICE_MAC_IPV6_GTPC_TEID			326
+#define ICE_MAC_IPV4_GTPC			327
+#define ICE_MAC_IPV6_GTPC			328
+#define ICE_MAC_IPV4_GTPU			329
+#define ICE_MAC_IPV6_GTPU			330
+#define ICE_MAC_IPV4_GTPU_IPV4_FRAG		331
+#define ICE_MAC_IPV4_GTPU_IPV4_PAY		332
+#define ICE_MAC_IPV4_GTPU_IPV4_UDP_PAY		333
+#define ICE_MAC_IPV4_GTPU_IPV4_TCP		334
+#define ICE_MAC_IPV4_GTPU_IPV4_ICMP		335
+#define ICE_MAC_IPV6_GTPU_IPV4_FRAG		336
+#define ICE_MAC_IPV6_GTPU_IPV4_PAY		337
+#define ICE_MAC_IPV6_GTPU_IPV4_UDP_PAY		338
+#define ICE_MAC_IPV6_GTPU_IPV4_TCP		339
+#define ICE_MAC_IPV6_GTPU_IPV4_ICMP		340
+#define ICE_MAC_IPV4_GTPU_IPV6_FRAG		341
+#define ICE_MAC_IPV4_GTPU_IPV6_PAY		342
+#define ICE_MAC_IPV4_GTPU_IPV6_UDP_PAY		343
+#define ICE_MAC_IPV4_GTPU_IPV6_TCP		344
+#define ICE_MAC_IPV4_GTPU_IPV6_ICMPV6		345
+#define ICE_MAC_IPV6_GTPU_IPV6_FRAG		346
+#define ICE_MAC_IPV6_GTPU_IPV6_PAY		347
+#define ICE_MAC_IPV6_GTPU_IPV6_UDP_PAY		348
+#define ICE_MAC_IPV6_GTPU_IPV6_TCP		349
+#define ICE_MAC_IPV6_GTPU_IPV6_ICMPV6		350
+#define ICE_MAC_IPV4_PFCP_NODE			351
+#define ICE_MAC_IPV4_PFCP_SESSION		352
+#define ICE_MAC_IPV6_PFCP_NODE			353
+#define ICE_MAC_IPV6_PFCP_SESSION		354
+#define ICE_MAC_IPV4_L2TPV3			360
+#define ICE_MAC_IPV6_L2TPV3			361
+
 
 /* Attributes that can modify PTYPE definitions.
  *
-- 
2.20.1

[dpdk-dev] [dpdk-dev v4 2/2] net/ice: refactor PTYPE parsing

[Jeff Guo]

If the capability of a PTYPE within a specific package could be
negotiated, no need to maintain a different PTYPE list for each
type of the package when parsing PTYPE. So refactor the PTYPE
parsing mechanism for each flow engines.

Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
 drivers/net/ice/ice_acl_filter.c    |   3 +-
 drivers/net/ice/ice_fdir_filter.c   |  63 ++-----------
 drivers/net/ice/ice_generic_flow.c  | 132 ++++++++++++++++++++++++--
 drivers/net/ice/ice_generic_flow.h  |   9 +-
 drivers/net/ice/ice_hash.c          |  51 ++--------
 drivers/net/ice/ice_switch_filter.c | 139 ++++------------------------
 6 files changed, 165 insertions(+), 232 deletions(-)

diff --git a/drivers/net/ice/ice_acl_filter.c b/drivers/net/ice/ice_acl_filter.c
index f7dbe53574..363ce68318 100644
--- a/drivers/net/ice/ice_acl_filter.c
+++ b/drivers/net/ice/ice_acl_filter.c
@@ -914,7 +914,8 @@ ice_acl_parse(struct ice_adapter *ad,
 	int ret;
 
 	memset(filter, 0, sizeof(*filter));
-	item = ice_search_pattern_match_item(pattern, array, array_len, error);
+	item = ice_search_pattern_match_item(ad, pattern, array, array_len,
+					     error);
 	if (!item)
 		return -rte_errno;
 
diff --git a/drivers/net/ice/ice_fdir_filter.c b/drivers/net/ice/ice_fdir_filter.c
index 175abcdd5c..ce6aa09d3d 100644
--- a/drivers/net/ice/ice_fdir_filter.c
+++ b/drivers/net/ice/ice_fdir_filter.c
@@ -84,34 +84,7 @@
 	ICE_INSET_IPV6_SRC | ICE_INSET_IPV6_DST | \
 	ICE_INSET_GTPU_TEID | ICE_INSET_GTPU_QFI)
 
-static struct ice_pattern_match_item ice_fdir_pattern_os[] = {
-	{pattern_eth_ipv4,             ICE_FDIR_INSET_ETH_IPV4,              ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp,         ICE_FDIR_INSET_ETH_IPV4_UDP,          ICE_INSET_NONE},
-	{pattern_eth_ipv4_tcp,         ICE_FDIR_INSET_ETH_IPV4_TCP,          ICE_INSET_NONE},
-	{pattern_eth_ipv4_sctp,        ICE_FDIR_INSET_ETH_IPV4_SCTP,         ICE_INSET_NONE},
-	{pattern_eth_ipv6,             ICE_FDIR_INSET_ETH_IPV6,              ICE_INSET_NONE},
-	{pattern_eth_ipv6_udp,         ICE_FDIR_INSET_ETH_IPV6_UDP,          ICE_INSET_NONE},
-	{pattern_eth_ipv6_tcp,         ICE_FDIR_INSET_ETH_IPV6_TCP,          ICE_INSET_NONE},
-	{pattern_eth_ipv6_sctp,        ICE_FDIR_INSET_ETH_IPV6_SCTP,         ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_ipv4,
-				       ICE_FDIR_INSET_VXLAN_IPV4,            ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_ipv4_udp,
-				       ICE_FDIR_INSET_VXLAN_IPV4_UDP,        ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_ipv4_tcp,
-				       ICE_FDIR_INSET_VXLAN_IPV4_TCP,        ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_ipv4_sctp,
-				       ICE_FDIR_INSET_VXLAN_IPV4_SCTP,       ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4,
-				       ICE_FDIR_INSET_VXLAN_IPV4,            ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_udp,
-				       ICE_FDIR_INSET_VXLAN_IPV4_UDP,        ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_tcp,
-				       ICE_FDIR_INSET_VXLAN_IPV4_TCP,        ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_sctp,
-				       ICE_FDIR_INSET_VXLAN_IPV4_SCTP,       ICE_INSET_NONE},
-};
-
-static struct ice_pattern_match_item ice_fdir_pattern_comms[] = {
+static struct ice_pattern_match_item ice_fdir_pattern_list[] = {
 	{pattern_ethertype,	       ICE_FDIR_INSET_ETH,		     ICE_INSET_NONE},
 	{pattern_eth_ipv4,             ICE_FDIR_INSET_ETH_IPV4,              ICE_INSET_NONE},
 	{pattern_eth_ipv4_udp,         ICE_FDIR_INSET_ETH_IPV4_UDP,          ICE_INSET_NONE},
@@ -143,8 +116,7 @@ static struct ice_pattern_match_item ice_fdir_pattern_comms[] = {
 	{pattern_eth_ipv6_gtpu_eh,     ICE_FDIR_INSET_IPV6_GTPU_EH,          ICE_INSET_NONE},
 };
 
-static struct ice_flow_parser ice_fdir_parser_os;
-static struct ice_flow_parser ice_fdir_parser_comms;
+static struct ice_flow_parser ice_fdir_parser;
 
 static int
 ice_fdir_is_tunnel_profile(enum ice_fdir_tunnel_type tunnel_type);
@@ -1111,12 +1083,7 @@ ice_fdir_init(struct ice_adapter *ad)
 	if (ret)
 		return ret;
 
-	if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
-		parser = &ice_fdir_parser_comms;
-	else if (ad->active_pkg_type == ICE_PKG_TYPE_OS_DEFAULT)
-		parser = &ice_fdir_parser_os;
-	else
-		return -EINVAL;
+	parser = &ice_fdir_parser;
 
 	return ice_register_parser(parser, ad);
 }
@@ -1124,16 +1091,13 @@ ice_fdir_init(struct ice_adapter *ad)
 static void
 ice_fdir_uninit(struct ice_adapter *ad)
 {
-	struct ice_pf *pf = &ad->pf;
 	struct ice_flow_parser *parser;
+	struct ice_pf *pf = &ad->pf;
 
 	if (ad->hw.dcf_enabled)
 		return;
 
-	if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
-		parser = &ice_fdir_parser_comms;
-	else
-		parser = &ice_fdir_parser_os;
+	parser = &ice_fdir_parser;
 
 	ice_unregister_parser(parser, ad);
 
@@ -2039,7 +2003,8 @@ ice_fdir_parse(struct ice_adapter *ad,
 	int ret;
 
 	memset(filter, 0, sizeof(*filter));
-	item = ice_search_pattern_match_item(pattern, array, array_len, error);
+	item = ice_search_pattern_match_item(ad, pattern, array, array_len,
+					     error);
 	if (!item)
 		return -rte_errno;
 
@@ -2067,18 +2032,10 @@ ice_fdir_parse(struct ice_adapter *ad,
 	return ret;
 }
 
-static struct ice_flow_parser ice_fdir_parser_os = {
-	.engine = &ice_fdir_engine,
-	.array = ice_fdir_pattern_os,
-	.array_len = RTE_DIM(ice_fdir_pattern_os),
-	.parse_pattern_action = ice_fdir_parse,
-	.stage = ICE_FLOW_STAGE_DISTRIBUTOR,
-};
-
-static struct ice_flow_parser ice_fdir_parser_comms = {
+static struct ice_flow_parser ice_fdir_parser = {
 	.engine = &ice_fdir_engine,
-	.array = ice_fdir_pattern_comms,
-	.array_len = RTE_DIM(ice_fdir_pattern_comms),
+	.array = ice_fdir_pattern_list,
+	.array_len = RTE_DIM(ice_fdir_pattern_list),
 	.parse_pattern_action = ice_fdir_parse,
 	.stage = ICE_FLOW_STAGE_DISTRIBUTOR,
 };
diff --git a/drivers/net/ice/ice_generic_flow.c b/drivers/net/ice/ice_generic_flow.c
index 1429cbc3b6..4313aae183 100644
--- a/drivers/net/ice/ice_generic_flow.c
+++ b/drivers/net/ice/ice_generic_flow.c
@@ -2046,17 +2046,127 @@ ice_match_pattern(enum rte_flow_item_type *item_array,
 		item->type == RTE_FLOW_ITEM_TYPE_END);
 }
 
+struct ice_ptype_match {
+	enum rte_flow_item_type *pattern_list;
+	uint16_t hw_ptype;
+};
+
+static struct ice_ptype_match ice_ptype_map[] = {
+	{pattern_eth_ipv4,				ICE_PTYPE_IPV4_PAY},
+	{pattern_eth_ipv4_udp,				ICE_PTYPE_IPV4_UDP_PAY},
+	{pattern_eth_ipv4_tcp,				ICE_PTYPE_IPV4_TCP_PAY},
+	{pattern_eth_ipv4_sctp,				ICE_PTYPE_IPV4_SCTP_PAY},
+	{pattern_eth_ipv4_gtpu,				ICE_MAC_IPV4_GTPU},
+	{pattern_eth_ipv4_gtpu_eh,			ICE_MAC_IPV4_GTPU},
+	{pattern_eth_ipv4_gtpu_ipv4,			ICE_MAC_IPV4_GTPU_IPV4_PAY},
+	{pattern_eth_ipv4_gtpu_ipv4_udp,		ICE_MAC_IPV4_GTPU_IPV4_UDP_PAY},
+	{pattern_eth_ipv4_gtpu_ipv4_tcp,		ICE_MAC_IPV4_GTPU_IPV4_TCP},
+	{pattern_eth_ipv4_gtpu_ipv6,			ICE_MAC_IPV4_GTPU_IPV6_PAY},
+	{pattern_eth_ipv4_gtpu_ipv6_udp,		ICE_MAC_IPV4_GTPU_IPV6_UDP_PAY},
+	{pattern_eth_ipv4_gtpu_ipv6_tcp,		ICE_MAC_IPV4_GTPU_IPV6_TCP},
+	{pattern_eth_ipv4_gtpu_eh_ipv4,			ICE_MAC_IPV4_GTPU_IPV4_PAY},
+	{pattern_eth_ipv4_gtpu_eh_ipv4_udp,		ICE_MAC_IPV4_GTPU_IPV4_UDP_PAY},
+	{pattern_eth_ipv4_gtpu_eh_ipv4_tcp,		ICE_MAC_IPV4_GTPU_IPV4_TCP},
+	{pattern_eth_ipv4_gtpu_eh_ipv6,			ICE_MAC_IPV4_GTPU_IPV6_PAY},
+	{pattern_eth_ipv4_gtpu_eh_ipv6_udp,		ICE_MAC_IPV4_GTPU_IPV6_UDP_PAY},
+	{pattern_eth_ipv4_gtpu_eh_ipv6_tcp,		ICE_MAC_IPV4_GTPU_IPV6_TCP},
+	{pattern_eth_ipv4_esp,				ICE_MAC_IPV4_ESP},
+	{pattern_eth_ipv4_udp_esp,			ICE_MAC_IPV4_NAT_T_ESP},
+	{pattern_eth_ipv4_ah,				ICE_MAC_IPV4_AH},
+	{pattern_eth_ipv4_l2tp,				ICE_MAC_IPV4_L2TPV3},
+	{pattern_eth_ipv4_pfcp,				ICE_MAC_IPV4_PFCP_SESSION},
+	{pattern_eth_ipv6,				ICE_PTYPE_IPV6_PAY},
+	{pattern_eth_ipv6_udp,				ICE_PTYPE_IPV6_UDP_PAY},
+	{pattern_eth_ipv6_tcp,				ICE_PTYPE_IPV6_TCP_PAY},
+	{pattern_eth_ipv6_sctp,				ICE_PTYPE_IPV6_SCTP_PAY},
+	{pattern_eth_ipv6_gtpu,				ICE_MAC_IPV6_GTPU},
+	{pattern_eth_ipv6_gtpu_eh,			ICE_MAC_IPV6_GTPU},
+	{pattern_eth_ipv6_gtpu_ipv4,			ICE_MAC_IPV6_GTPU_IPV4_PAY},
+	{pattern_eth_ipv6_gtpu_ipv4_udp,		ICE_MAC_IPV6_GTPU_IPV4_UDP_PAY},
+	{pattern_eth_ipv6_gtpu_ipv4_tcp,		ICE_MAC_IPV6_GTPU_IPV4_TCP},
+	{pattern_eth_ipv6_gtpu_ipv6,			ICE_MAC_IPV6_GTPU_IPV6_PAY},
+	{pattern_eth_ipv6_gtpu_ipv6_udp,		ICE_MAC_IPV6_GTPU_IPV6_UDP_PAY},
+	{pattern_eth_ipv6_gtpu_ipv6_tcp,		ICE_MAC_IPV6_GTPU_IPV6_TCP},
+	{pattern_eth_ipv6_gtpu_eh_ipv4,			ICE_MAC_IPV6_GTPU_IPV4_PAY},
+	{pattern_eth_ipv6_gtpu_eh_ipv4_udp,		ICE_MAC_IPV6_GTPU_IPV4_UDP_PAY},
+	{pattern_eth_ipv6_gtpu_eh_ipv4_tcp,		ICE_MAC_IPV6_GTPU_IPV4_TCP},
+	{pattern_eth_ipv6_gtpu_eh_ipv6,			ICE_MAC_IPV6_GTPU_IPV6_PAY},
+	{pattern_eth_ipv6_gtpu_eh_ipv6_udp,		ICE_MAC_IPV6_GTPU_IPV6_UDP_PAY},
+	{pattern_eth_ipv6_gtpu_eh_ipv6_tcp,		ICE_MAC_IPV6_GTPU_IPV6_TCP},
+	{pattern_eth_ipv6_esp,				ICE_MAC_IPV6_ESP},
+	{pattern_eth_ipv6_udp_esp,			ICE_MAC_IPV6_NAT_T_ESP},
+	{pattern_eth_ipv6_ah,				ICE_MAC_IPV6_AH},
+	{pattern_eth_ipv6_l2tp,				ICE_MAC_IPV6_L2TPV3},
+	{pattern_eth_ipv6_pfcp,				ICE_MAC_IPV6_PFCP_SESSION},
+	{pattern_ethertype,				ICE_PTYPE_MAC_PAY},
+	{pattern_ethertype_vlan,			ICE_PTYPE_MAC_PAY},
+	{pattern_eth_arp,				ICE_PTYPE_MAC_PAY},
+	{pattern_eth_vlan_ipv4,				ICE_PTYPE_IPV4_PAY},
+	{pattern_eth_vlan_ipv4_udp,			ICE_PTYPE_IPV4_UDP_PAY},
+	{pattern_eth_vlan_ipv4_tcp,			ICE_PTYPE_IPV4_TCP_PAY},
+	{pattern_eth_vlan_ipv4_sctp,			ICE_PTYPE_IPV4_SCTP_PAY},
+	{pattern_eth_vlan_ipv6,				ICE_PTYPE_IPV6_PAY},
+	{pattern_eth_vlan_ipv6_udp,			ICE_PTYPE_IPV6_UDP_PAY},
+	{pattern_eth_vlan_ipv6_tcp,			ICE_PTYPE_IPV6_TCP_PAY},
+	{pattern_eth_vlan_ipv6_sctp,			ICE_PTYPE_IPV6_SCTP_PAY},
+	{pattern_eth_pppoes,				ICE_MAC_PPPOE_PAY},
+	{pattern_eth_vlan_pppoes,			ICE_MAC_PPPOE_PAY},
+	{pattern_eth_pppoes_proto,			ICE_MAC_PPPOE_PAY},
+	{pattern_eth_vlan_pppoes_proto,			ICE_MAC_PPPOE_PAY},
+	{pattern_eth_pppoes_ipv4,			ICE_MAC_PPPOE_IPV4_PAY},
+	{pattern_eth_pppoes_ipv4_udp,			ICE_MAC_PPPOE_IPV4_UDP_PAY},
+	{pattern_eth_pppoes_ipv4_tcp,			ICE_MAC_PPPOE_IPV4_TCP},
+	{pattern_eth_vlan_pppoes_ipv4,			ICE_MAC_PPPOE_IPV4_PAY},
+	{pattern_eth_vlan_pppoes_ipv4_tcp,		ICE_MAC_PPPOE_IPV4_TCP},
+	{pattern_eth_vlan_pppoes_ipv4_udp,		ICE_MAC_PPPOE_IPV4_UDP_PAY},
+	{pattern_eth_pppoes_ipv6,			ICE_MAC_PPPOE_IPV6_PAY},
+	{pattern_eth_pppoes_ipv6_udp,			ICE_MAC_PPPOE_IPV6_UDP_PAY},
+	{pattern_eth_pppoes_ipv6_tcp,			ICE_MAC_PPPOE_IPV6_TCP},
+	{pattern_eth_vlan_pppoes_ipv6,			ICE_MAC_PPPOE_IPV6_PAY},
+	{pattern_eth_vlan_pppoes_ipv6_tcp,		ICE_MAC_PPPOE_IPV6_TCP},
+	{pattern_eth_vlan_pppoes_ipv6_udp,		ICE_MAC_PPPOE_IPV6_UDP_PAY},
+	{pattern_eth_ipv4_udp_vxlan_ipv4,		ICE_MAC_IPV4_TUN_IPV4_PAY},
+	{pattern_eth_ipv4_udp_vxlan_ipv4_udp,		ICE_MAC_IPV4_TUN_IPV4_UDP_PAY},
+	{pattern_eth_ipv4_udp_vxlan_ipv4_tcp,		ICE_MAC_IPV4_TUN_IPV4_TCP},
+	{pattern_eth_ipv4_udp_vxlan_ipv4_sctp,		ICE_MAC_IPV4_TUN_IPV4_SCTP},
+	{pattern_eth_ipv4_udp_vxlan_eth_ipv4,		ICE_MAC_IPV4_TUN_IPV4_PAY},
+	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_udp,	ICE_MAC_IPV4_TUN_IPV4_UDP_PAY},
+	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_tcp,	ICE_MAC_IPV4_TUN_IPV4_TCP},
+	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_sctp,	ICE_MAC_IPV4_TUN_IPV4_SCTP},
+	{pattern_eth_ipv4_nvgre_eth_ipv4,		ICE_MAC_IPV4_TUN_IPV4_PAY},
+	{pattern_eth_ipv4_nvgre_eth_ipv4_udp,		ICE_MAC_IPV4_TUN_IPV4_UDP_PAY},
+	{pattern_eth_ipv4_nvgre_eth_ipv4_tcp,		ICE_MAC_IPV4_TUN_IPV4_TCP},
+};
+
+static bool
+ice_pattern_is_supported(__rte_unused struct ice_adapter *ad,
+			 const struct rte_flow_item *pattern)
+{
+	uint16_t i;
+
+	for (i = 0; i < RTE_DIM(ice_ptype_map); i++) {
+		if (ice_match_pattern(ice_ptype_map[i].pattern_list,
+				      pattern)) {
+			return ice_hw_ptype_ena(&ad->hw,
+						ice_ptype_map[i].hw_ptype);
+		}
+	}
+
+	return false;
+}
+
 struct ice_pattern_match_item *
-ice_search_pattern_match_item(const struct rte_flow_item pattern[],
-		struct ice_pattern_match_item *array,
-		uint32_t array_len,
-		struct rte_flow_error *error)
+ice_search_pattern_match_item(struct ice_adapter *ad,
+			      const struct rte_flow_item pattern[],
+			      struct ice_pattern_match_item *array,
+			      uint32_t array_len,
+			      struct rte_flow_error *error)
 {
-	uint16_t i = 0;
 	struct ice_pattern_match_item *pattern_match_item;
 	/* need free by each filter */
 	struct rte_flow_item *items; /* used for pattern without VOID items */
 	uint32_t item_num = 0; /* non-void item number */
+	uint16_t i = 0;
 
 	/* Get the non-void item number of pattern */
 	while ((pattern + i)->type != RTE_FLOW_ITEM_TYPE_END) {
@@ -2078,14 +2188,18 @@ ice_search_pattern_match_item(const struct rte_flow_item pattern[],
 	if (!pattern_match_item) {
 		rte_flow_error_set(error, ENOMEM, RTE_FLOW_ERROR_TYPE_HANDLE,
 				NULL, "Failed to allocate memory.");
+		rte_free(items);
 		return NULL;
 	}
 
 	ice_pattern_skip_void_item(items, pattern);
 
-	for (i = 0; i < array_len; i++)
+	if (!ice_pattern_is_supported(ad, pattern))
+		goto unsupported;
+
+	for (i = 0; i < array_len; i++) {
 		if (ice_match_pattern(array[i].pattern_list,
-					items)) {
+				      items)) {
 			pattern_match_item->input_set_mask =
 				array[i].input_set_mask;
 			pattern_match_item->pattern_list =
@@ -2094,9 +2208,11 @@ ice_search_pattern_match_item(const struct rte_flow_item pattern[],
 			rte_free(items);
 			return pattern_match_item;
 		}
+	}
+
+unsupported:
 	rte_flow_error_set(error, EINVAL, RTE_FLOW_ERROR_TYPE_ITEM,
 			   pattern, "Unsupported pattern");
-
 	rte_free(items);
 	rte_free(pattern_match_item);
 	return NULL;
diff --git a/drivers/net/ice/ice_generic_flow.h b/drivers/net/ice/ice_generic_flow.h
index 434d2f425d..0dcb620809 100644
--- a/drivers/net/ice/ice_generic_flow.h
+++ b/drivers/net/ice/ice_generic_flow.h
@@ -593,10 +593,11 @@ int ice_register_parser(struct ice_flow_parser *parser,
 void ice_unregister_parser(struct ice_flow_parser *parser,
 		struct ice_adapter *ad);
 struct ice_pattern_match_item *
-ice_search_pattern_match_item(const struct rte_flow_item pattern[],
-		struct ice_pattern_match_item *array,
-		uint32_t array_len,
-		struct rte_flow_error *error);
+ice_search_pattern_match_item(struct ice_adapter *ad,
+			      const struct rte_flow_item pattern[],
+			      struct ice_pattern_match_item *array,
+			      uint32_t array_len,
+			      struct rte_flow_error *error);
 int
 ice_flow_redirect(struct ice_adapter *ad,
 		  struct ice_flow_redirect *rd);
diff --git a/drivers/net/ice/ice_hash.c b/drivers/net/ice/ice_hash.c
index c3ab4a0ccb..3940438c81 100644
--- a/drivers/net/ice/ice_hash.c
+++ b/drivers/net/ice/ice_hash.c
@@ -397,25 +397,7 @@ struct ice_rss_hash_cfg empty_tmplt = {
  * the second member is input set mask,
  * the third member is ice_rss_hash_cfg template.
  */
-
-/* Supported pattern for os default package. */
-static struct ice_pattern_match_item ice_hash_pattern_list_os[] = {
-	/* IPV4 */
-	{pattern_eth_ipv4,			ICE_RSS_TYPE_OUTER_IPV4,	&ipv4_tmplt},
-	{pattern_eth_ipv4_udp,			ICE_RSS_TYPE_OUTER_IPV4_UDP,	&ipv4_udp_tmplt},
-	{pattern_eth_ipv4_tcp,			ICE_RSS_TYPE_OUTER_IPV4_TCP,	&ipv4_tcp_tmplt},
-	{pattern_eth_ipv4_sctp,			ICE_RSS_TYPE_OUTER_IPV4_SCTP,	&ipv4_sctp_tmplt},
-	/* IPV6 */
-	{pattern_eth_ipv6,			ICE_RSS_TYPE_OUTER_IPV6,	&ipv6_tmplt},
-	{pattern_eth_ipv6_udp,			ICE_RSS_TYPE_OUTER_IPV6_UDP,	&ipv6_udp_tmplt},
-	{pattern_eth_ipv6_tcp,			ICE_RSS_TYPE_OUTER_IPV6_TCP,	&ipv6_tcp_tmplt},
-	{pattern_eth_ipv6_sctp,			ICE_RSS_TYPE_OUTER_IPV6_SCTP,	&ipv6_sctp_tmplt},
-	/* EMPTY */
-	{pattern_empty,				ICE_RSS_TYPE_EMPTY,		&empty_tmplt},
-};
-
-/* Supported pattern for comms package. */
-static struct ice_pattern_match_item ice_hash_pattern_list_comms[] = {
+static struct ice_pattern_match_item ice_hash_pattern_list[] = {
 	/* IPV4 */
 	{pattern_eth_ipv4,			ICE_RSS_TYPE_OUTER_IPV4,	&ipv4_tmplt},
 	{pattern_eth_ipv4_udp,			ICE_RSS_TYPE_OUTER_IPV4_UDP,	&ipv4_udp_tmplt},
@@ -490,19 +472,10 @@ static struct ice_flow_engine ice_hash_engine = {
 };
 
 /* Register parser for os package. */
-static struct ice_flow_parser ice_hash_parser_os = {
-	.engine = &ice_hash_engine,
-	.array = ice_hash_pattern_list_os,
-	.array_len = RTE_DIM(ice_hash_pattern_list_os),
-	.parse_pattern_action = ice_hash_parse_pattern_action,
-	.stage = ICE_FLOW_STAGE_RSS,
-};
-
-/* Register parser for comms package. */
-static struct ice_flow_parser ice_hash_parser_comms = {
+static struct ice_flow_parser ice_hash_parser = {
 	.engine = &ice_hash_engine,
-	.array = ice_hash_pattern_list_comms,
-	.array_len = RTE_DIM(ice_hash_pattern_list_comms),
+	.array = ice_hash_pattern_list,
+	.array_len = RTE_DIM(ice_hash_pattern_list),
 	.parse_pattern_action = ice_hash_parse_pattern_action,
 	.stage = ICE_FLOW_STAGE_RSS,
 };
@@ -521,12 +494,7 @@ ice_hash_init(struct ice_adapter *ad)
 	if (ad->hw.dcf_enabled)
 		return 0;
 
-	if (ad->active_pkg_type == ICE_PKG_TYPE_OS_DEFAULT)
-		parser = &ice_hash_parser_os;
-	else if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
-		parser = &ice_hash_parser_comms;
-	else
-		return -EINVAL;
+	parser = &ice_hash_parser;
 
 	return ice_register_parser(parser, ad);
 }
@@ -970,8 +938,8 @@ ice_hash_parse_pattern_action(__rte_unused struct ice_adapter *ad,
 	}
 
 	/* Check rss supported pattern and find matched pattern. */
-	pattern_match_item = ice_search_pattern_match_item(pattern,
-					array, array_len, error);
+	pattern_match_item = ice_search_pattern_match_item(ad, pattern, array,
+							   array_len, error);
 	if (!pattern_match_item) {
 		ret = -rte_errno;
 		goto error;
@@ -1103,10 +1071,7 @@ ice_hash_uninit(struct ice_adapter *ad)
 	if (ad->hw.dcf_enabled)
 		return;
 
-	if (ad->active_pkg_type == ICE_PKG_TYPE_OS_DEFAULT)
-		ice_unregister_parser(&ice_hash_parser_os, ad);
-	else if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
-		ice_unregister_parser(&ice_hash_parser_comms, ad);
+	ice_unregister_parser(&ice_hash_parser, ad);
 }
 
 static void
diff --git a/drivers/net/ice/ice_switch_filter.c b/drivers/net/ice/ice_switch_filter.c
index 8cba6eb7b1..e5b7d56068 100644
--- a/drivers/net/ice/ice_switch_filter.c
+++ b/drivers/net/ice/ice_switch_filter.c
@@ -137,47 +137,11 @@ struct sw_meta {
 	struct ice_adv_rule_info rule_info;
 };
 
-static struct ice_flow_parser ice_switch_dist_parser_os;
-static struct ice_flow_parser ice_switch_dist_parser_comms;
-static struct ice_flow_parser ice_switch_perm_parser_os;
-static struct ice_flow_parser ice_switch_perm_parser_comms;
+static struct ice_flow_parser ice_switch_dist_parser;
+static struct ice_flow_parser ice_switch_perm_parser;
 
 static struct
-ice_pattern_match_item ice_switch_pattern_dist_os[] = {
-	{pattern_ethertype,
-			ICE_SW_INSET_ETHER, ICE_INSET_NONE},
-	{pattern_ethertype_vlan,
-			ICE_SW_INSET_MAC_VLAN, ICE_INSET_NONE},
-	{pattern_eth_arp,
-			ICE_INSET_NONE, ICE_INSET_NONE},
-	{pattern_eth_ipv4,
-			ICE_SW_INSET_MAC_IPV4, ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp,
-			ICE_SW_INSET_MAC_IPV4_UDP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_tcp,
-			ICE_SW_INSET_MAC_IPV4_TCP, ICE_INSET_NONE},
-	{pattern_eth_ipv6,
-			ICE_SW_INSET_MAC_IPV6, ICE_INSET_NONE},
-	{pattern_eth_ipv6_udp,
-			ICE_SW_INSET_MAC_IPV6_UDP, ICE_INSET_NONE},
-	{pattern_eth_ipv6_tcp,
-			ICE_SW_INSET_MAC_IPV6_TCP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4,
-			ICE_SW_INSET_DIST_VXLAN_IPV4, ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_udp,
-			ICE_SW_INSET_DIST_VXLAN_IPV4_UDP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_tcp,
-			ICE_SW_INSET_DIST_VXLAN_IPV4_TCP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_nvgre_eth_ipv4,
-			ICE_SW_INSET_DIST_NVGRE_IPV4, ICE_INSET_NONE},
-	{pattern_eth_ipv4_nvgre_eth_ipv4_udp,
-			ICE_SW_INSET_DIST_NVGRE_IPV4_UDP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_nvgre_eth_ipv4_tcp,
-			ICE_SW_INSET_DIST_NVGRE_IPV4_TCP, ICE_INSET_NONE},
-};
-
-static struct
-ice_pattern_match_item ice_switch_pattern_dist_comms[] = {
+ice_pattern_match_item ice_switch_pattern_dist_list[] = {
 	{pattern_ethertype,
 			ICE_SW_INSET_ETHER, ICE_INSET_NONE},
 	{pattern_ethertype_vlan,
@@ -265,41 +229,7 @@ ice_pattern_match_item ice_switch_pattern_dist_comms[] = {
 };
 
 static struct
-ice_pattern_match_item ice_switch_pattern_perm_os[] = {
-	{pattern_ethertype,
-			ICE_SW_INSET_ETHER, ICE_INSET_NONE},
-	{pattern_ethertype_vlan,
-			ICE_SW_INSET_MAC_VLAN, ICE_INSET_NONE},
-	{pattern_eth_arp,
-			ICE_INSET_NONE, ICE_INSET_NONE},
-	{pattern_eth_ipv4,
-			ICE_SW_INSET_MAC_IPV4, ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp,
-			ICE_SW_INSET_MAC_IPV4_UDP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_tcp,
-			ICE_SW_INSET_MAC_IPV4_TCP, ICE_INSET_NONE},
-	{pattern_eth_ipv6,
-			ICE_SW_INSET_MAC_IPV6, ICE_INSET_NONE},
-	{pattern_eth_ipv6_udp,
-			ICE_SW_INSET_MAC_IPV6_UDP, ICE_INSET_NONE},
-	{pattern_eth_ipv6_tcp,
-			ICE_SW_INSET_MAC_IPV6_TCP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4,
-			ICE_SW_INSET_PERM_TUNNEL_IPV4, ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_udp,
-			ICE_SW_INSET_PERM_TUNNEL_IPV4_UDP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_udp_vxlan_eth_ipv4_tcp,
-			ICE_SW_INSET_PERM_TUNNEL_IPV4_TCP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_nvgre_eth_ipv4,
-			ICE_SW_INSET_PERM_TUNNEL_IPV4, ICE_INSET_NONE},
-	{pattern_eth_ipv4_nvgre_eth_ipv4_udp,
-			ICE_SW_INSET_PERM_TUNNEL_IPV4_UDP, ICE_INSET_NONE},
-	{pattern_eth_ipv4_nvgre_eth_ipv4_tcp,
-			ICE_SW_INSET_PERM_TUNNEL_IPV4_TCP, ICE_INSET_NONE},
-};
-
-static struct
-ice_pattern_match_item ice_switch_pattern_perm_comms[] = {
+ice_pattern_match_item ice_switch_pattern_perm_list[] = {
 	{pattern_ethertype,
 			ICE_SW_INSET_ETHER, ICE_INSET_NONE},
 	{pattern_ethertype_vlan,
@@ -1699,7 +1629,8 @@ ice_switch_parse_pattern_action(struct ice_adapter *ad,
 	}
 
 	pattern_match_item =
-		ice_search_pattern_match_item(pattern, array, array_len, error);
+		ice_search_pattern_match_item(ad, pattern, array, array_len,
+					      error);
 	if (!pattern_match_item) {
 		rte_flow_error_set(error, EINVAL,
 				   RTE_FLOW_ERROR_TYPE_HANDLE, NULL,
@@ -1859,21 +1790,11 @@ ice_switch_init(struct ice_adapter *ad)
 	struct ice_flow_parser *dist_parser;
 	struct ice_flow_parser *perm_parser;
 
-	if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
-		dist_parser = &ice_switch_dist_parser_comms;
-	else if (ad->active_pkg_type == ICE_PKG_TYPE_OS_DEFAULT)
-		dist_parser = &ice_switch_dist_parser_os;
-	else
-		return -EINVAL;
-
 	if (ad->devargs.pipe_mode_support) {
-		if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
-			perm_parser = &ice_switch_perm_parser_comms;
-		else
-			perm_parser = &ice_switch_perm_parser_os;
-
+		perm_parser = &ice_switch_perm_parser;
 		ret = ice_register_parser(perm_parser, ad);
 	} else {
+		dist_parser = &ice_switch_dist_parser;
 		ret = ice_register_parser(dist_parser, ad);
 	}
 	return ret;
@@ -1885,21 +1806,11 @@ ice_switch_uninit(struct ice_adapter *ad)
 	struct ice_flow_parser *dist_parser;
 	struct ice_flow_parser *perm_parser;
 
-	if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
-		dist_parser = &ice_switch_dist_parser_comms;
-	else if (ad->active_pkg_type == ICE_PKG_TYPE_OS_DEFAULT)
-		dist_parser = &ice_switch_dist_parser_os;
-	else
-		return;
-
 	if (ad->devargs.pipe_mode_support) {
-		if (ad->active_pkg_type == ICE_PKG_TYPE_COMMS)
-			perm_parser = &ice_switch_perm_parser_comms;
-		else
-			perm_parser = &ice_switch_perm_parser_os;
-
+		perm_parser = &ice_switch_perm_parser;
 		ice_unregister_parser(perm_parser, ad);
 	} else {
+		dist_parser = &ice_switch_dist_parser;
 		ice_unregister_parser(dist_parser, ad);
 	}
 }
@@ -1917,37 +1828,19 @@ ice_flow_engine ice_switch_engine = {
 };
 
 static struct
-ice_flow_parser ice_switch_dist_parser_os = {
+ice_flow_parser ice_switch_dist_parser = {
 	.engine = &ice_switch_engine,
-	.array = ice_switch_pattern_dist_os,
-	.array_len = RTE_DIM(ice_switch_pattern_dist_os),
+	.array = ice_switch_pattern_dist_list,
+	.array_len = RTE_DIM(ice_switch_pattern_dist_list),
 	.parse_pattern_action = ice_switch_parse_pattern_action,
 	.stage = ICE_FLOW_STAGE_DISTRIBUTOR,
 };
 
 static struct
-ice_flow_parser ice_switch_dist_parser_comms = {
-	.engine = &ice_switch_engine,
-	.array = ice_switch_pattern_dist_comms,
-	.array_len = RTE_DIM(ice_switch_pattern_dist_comms),
-	.parse_pattern_action = ice_switch_parse_pattern_action,
-	.stage = ICE_FLOW_STAGE_DISTRIBUTOR,
-};
-
-static struct
-ice_flow_parser ice_switch_perm_parser_os = {
-	.engine = &ice_switch_engine,
-	.array = ice_switch_pattern_perm_os,
-	.array_len = RTE_DIM(ice_switch_pattern_perm_os),
-	.parse_pattern_action = ice_switch_parse_pattern_action,
-	.stage = ICE_FLOW_STAGE_PERMISSION,
-};
-
-static struct
-ice_flow_parser ice_switch_perm_parser_comms = {
+ice_flow_parser ice_switch_perm_parser = {
 	.engine = &ice_switch_engine,
-	.array = ice_switch_pattern_perm_comms,
-	.array_len = RTE_DIM(ice_switch_pattern_perm_comms),
+	.array = ice_switch_pattern_perm_list,
+	.array_len = RTE_DIM(ice_switch_pattern_perm_list),
 	.parse_pattern_action = ice_switch_parse_pattern_action,
 	.stage = ICE_FLOW_STAGE_PERMISSION,
 };
-- 
2.20.1

Re: [dpdk-dev] [dpdk-dev v4 0/2] net/ice: refactor PTYPE parsing

[Zhang, Qi Z]

> -----Original Message-----
> From: Guo, Jia <jia.guo@intel.com>
> Sent: Wednesday, January 13, 2021 1:31 PM
> To: Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>;
> Yang, Qiming <qiming.yang@intel.com>; Wang, Haiyue
> <haiyue.wang@intel.com>
> Cc: dev@dpdk.org; Guo, Jia <jia.guo@intel.com>; Su, Simei
> <simei.su@intel.com>
> Subject: [dpdk-dev v4 0/2] net/ice: refactor PTYPE parsing
> 
> If the capability of a PTYPE within a specific package could be negotiated, no
> need to maintain a different PTYPE list for each type of the package when
> parsing PTYPE. So refactor the PTYPE parsing mechanism for each flow engines.
> 
> v4:
> rebase patch and add some more PTYPE macros
> 
> v3:
> separate the patch set from the ecpri configure patch set
> 
> Jeff Guo (2):
>   net/ice/base: add PTYPE value
>   net/ice: refactor PTYPE parsing
> 
>  drivers/net/ice/base/ice_flex_type.h | 189 +++++++++++++++++++++------
>  drivers/net/ice/ice_acl_filter.c     |   3 +-
>  drivers/net/ice/ice_fdir_filter.c    |  63 ++-------
>  drivers/net/ice/ice_generic_flow.c   | 132 +++++++++++++++++--
>  drivers/net/ice/ice_generic_flow.h   |   9 +-
>  drivers/net/ice/ice_hash.c           |  51 ++------
>  drivers/net/ice/ice_switch_filter.c  | 139 +++-----------------
>  7 files changed, 315 insertions(+), 271 deletions(-)
> 
> --
> 2.20.1

Acked-by: Qi Zhang <qi.z.zhang@intel.com>

Applied to dpdk-next-net-intel.

Thanks
Qi

[dpdk-dev] [dpdk-dev v3 0/3] enable UDP ecpri configure in dcf

[Jeff Guo]

Enabling ecpri UDP tunnel port configure in dcf.

v3:
seperate patch set.

v2:
refactor PTYPE parsing and add related sharecode patch separate patch set

Jeff Guo (3):
  net/ice: add PTYPE mapping for ecpri
  net/iavf: add PTYPE mapping for ecpri
  net/ice: enable ecpri tunnel port configure in dcf

 drivers/net/iavf/iavf_rxtx.c     | 44 +++++++++++++++++++++
 drivers/net/ice/ice_dcf_ethdev.c | 67 ++++++++++++++++++++++++++++++++
 drivers/net/ice/ice_rxtx.c       | 44 +++++++++++++++++++++
 3 files changed, 155 insertions(+)

-- 
2.20.1

[dpdk-dev] [dpdk-dev v3 1/3] net/ice: add PTYPE mapping for ecpri

[Jeff Guo]

Until the new ecpri PTYPE be added into the RTE lib, just mapping ecpri
to the PTYPE of RTE_PTYPE_L4_UDP in ice pmd.

Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
 drivers/net/ice/ice_rxtx.c | 44 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/drivers/net/ice/ice_rxtx.c b/drivers/net/ice/ice_rxtx.c
index d052bd0f1b..95be6f6791 100644
--- a/drivers/net/ice/ice_rxtx.c
+++ b/drivers/net/ice/ice_rxtx.c
@@ -3880,6 +3880,50 @@ ice_get_default_pkt_type(uint16_t ptype)
 			RTE_PTYPE_TUNNEL_GTPU |
 			RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN |
 			RTE_PTYPE_INNER_L4_ICMP,
+
+		/* IPv4 --> UDP ECPRI */
+		[372] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[373] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[374] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[375] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[376] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[377] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[378] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[379] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[380] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[381] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+
+		/* IPV6 --> UDP ECPRI */
+		[382] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[383] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[384] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[385] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[386] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[387] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[388] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[389] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[390] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[391] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
 		/* All others reserved */
 	};
 
-- 
2.20.1

[dpdk-dev] [dpdk-dev v3 2/3] net/iavf: add PTYPE mapping for ecpri

[Jeff Guo]

Until the new ecpri PTYPE be added into the RTE lib, just mapping ecpri
to the PTYPE of RTE_PTYPE_L4_UDP in iavf pmd.

Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
 drivers/net/iavf/iavf_rxtx.c | 44 ++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/drivers/net/iavf/iavf_rxtx.c b/drivers/net/iavf/iavf_rxtx.c
index d53d7b9840..1ddbad0f1f 100644
--- a/drivers/net/iavf/iavf_rxtx.c
+++ b/drivers/net/iavf/iavf_rxtx.c
@@ -3197,6 +3197,50 @@ iavf_get_default_ptype_table(void)
 			RTE_PTYPE_TUNNEL_GTPU |
 			RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN |
 			RTE_PTYPE_INNER_L4_ICMP,
+
+		/* IPv4 --> UDP ECPRI */
+		[372] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[373] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[374] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[375] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[376] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[377] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[378] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[379] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[380] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[381] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+
+		/* IPV6 --> UDP ECPRI */
+		[382] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[383] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[384] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[385] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[386] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[387] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[388] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[389] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[390] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
+		[391] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
+			RTE_PTYPE_L4_UDP,
 		/* All others reserved */
 	};
 
-- 
2.20.1

[dpdk-dev] [dpdk-dev v3 3/3] net/ice: enable ecpri tunnel port configure in dcf

[Jeff Guo]

Add ecpri tunnel port add and rm ops to configure ecpri udp tunnel port
in dcf.

Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
 drivers/net/ice/ice_dcf_ethdev.c | 67 ++++++++++++++++++++++++++++++++
 1 file changed, 67 insertions(+)

diff --git a/drivers/net/ice/ice_dcf_ethdev.c b/drivers/net/ice/ice_dcf_ethdev.c
index a9e78064d4..c8357f5054 100644
--- a/drivers/net/ice/ice_dcf_ethdev.c
+++ b/drivers/net/ice/ice_dcf_ethdev.c
@@ -26,6 +26,13 @@
 #include "ice_dcf_ethdev.h"
 #include "ice_rxtx.h"
 
+static int
+ice_dcf_dev_udp_tunnel_port_add(struct rte_eth_dev *dev,
+				struct rte_eth_udp_tunnel *udp_tunnel);
+static int
+ice_dcf_dev_udp_tunnel_port_del(struct rte_eth_dev *dev,
+				struct rte_eth_udp_tunnel *udp_tunnel);
+
 static uint16_t
 ice_dcf_recv_pkts(__rte_unused void *rx_queue,
 		  __rte_unused struct rte_mbuf **bufs,
@@ -870,6 +877,64 @@ ice_dcf_link_update(__rte_unused struct rte_eth_dev *dev,
 	return 0;
 }
 
+/* Add UDP tunneling port */
+static int
+ice_dcf_dev_udp_tunnel_port_add(struct rte_eth_dev *dev,
+				struct rte_eth_udp_tunnel *udp_tunnel)
+{
+	struct ice_dcf_adapter *adapter = dev->data->dev_private;
+	struct ice_adapter *parent_adapter = &adapter->parent;
+	struct ice_hw *parent_hw = &parent_adapter->hw;
+	int ret = 0;
+
+	if (!udp_tunnel)
+		return -EINVAL;
+
+	switch (udp_tunnel->prot_type) {
+	case RTE_TUNNEL_TYPE_VXLAN:
+		ret = ice_create_tunnel(parent_hw, TNL_VXLAN,
+					udp_tunnel->udp_port);
+		break;
+	case RTE_TUNNEL_TYPE_ECPRI:
+		ret = ice_create_tunnel(parent_hw, TNL_ECPRI,
+					udp_tunnel->udp_port);
+		break;
+	default:
+		PMD_DRV_LOG(ERR, "Invalid tunnel type");
+		ret = -EINVAL;
+		break;
+	}
+
+	return ret;
+}
+
+/* Delete UDP tunneling port */
+static int
+ice_dcf_dev_udp_tunnel_port_del(struct rte_eth_dev *dev,
+				struct rte_eth_udp_tunnel *udp_tunnel)
+{
+	struct ice_dcf_adapter *adapter = dev->data->dev_private;
+	struct ice_adapter *parent_adapter = &adapter->parent;
+	struct ice_hw *parent_hw = &parent_adapter->hw;
+	int ret = 0;
+
+	if (!udp_tunnel)
+		return -EINVAL;
+
+	switch (udp_tunnel->prot_type) {
+	case RTE_TUNNEL_TYPE_VXLAN:
+	case RTE_TUNNEL_TYPE_ECPRI:
+		ret = ice_destroy_tunnel(parent_hw, udp_tunnel->udp_port, 0);
+		break;
+	default:
+		PMD_DRV_LOG(ERR, "Invalid tunnel type");
+		ret = -EINVAL;
+		break;
+	}
+
+	return ret;
+}
+
 static const struct eth_dev_ops ice_dcf_eth_dev_ops = {
 	.dev_start               = ice_dcf_dev_start,
 	.dev_stop                = ice_dcf_dev_stop,
@@ -892,6 +957,8 @@ static const struct eth_dev_ops ice_dcf_eth_dev_ops = {
 	.allmulticast_enable     = ice_dcf_dev_allmulticast_enable,
 	.allmulticast_disable    = ice_dcf_dev_allmulticast_disable,
 	.filter_ctrl             = ice_dcf_dev_filter_ctrl,
+	.udp_tunnel_port_add	 = ice_dcf_dev_udp_tunnel_port_add,
+	.udp_tunnel_port_del	 = ice_dcf_dev_udp_tunnel_port_del,
 };
 
 static int
-- 
2.20.1

Re: [dpdk-dev] [dpdk-dev v3 0/3] enable UDP ecpri configure in dcf

[Zhang, Qi Z]

> -----Original Message-----
> From: Guo, Jia <jia.guo@intel.com>
> Sent: Wednesday, January 13, 2021 10:05 PM
> To: Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>;
> Yang, Qiming <qiming.yang@intel.com>; Wang, Haiyue
> <haiyue.wang@intel.com>
> Cc: dev@dpdk.org; Guo, Jia <jia.guo@intel.com>; Su, Simei
> <simei.su@intel.com>
> Subject: [dpdk-dev v3 0/3] enable UDP ecpri configure in dcf
> 
> Enabling ecpri UDP tunnel port configure in dcf.
> 
> v3:
> seperate patch set.
> 
> v2:
> refactor PTYPE parsing and add related sharecode patch separate patch set
> 
> Jeff Guo (3):
>   net/ice: add PTYPE mapping for ecpri
>   net/iavf: add PTYPE mapping for ecpri

For patch, 1,2 for new PTYPE mapping.

Acked-by: Qi Zhang <qi.z.zhang@intel.com>

Applied to dpdk-next-net-intel.

>   net/ice: enable ecpri tunnel port configure in dcf

For patch 3, it is depends on below patches
1. enable ecpri tunnel type .
http://patchwork.dpdk.org/patch/85702/
2. refine the description for rte_eth_dev_udp_tunnel_port_add
http://patchwork.dpdk.org/patch/86406/

Thomas, Ferruh:
	Please let us know if any issue for above patch merge.
Thanks
Qi

Re: [dpdk-dev] [dpdk-dev v3 0/3] enable UDP ecpri configure in dcf

[Ferruh Yigit]

On 1/14/2021 4:18 AM, Zhang, Qi Z wrote:
> 
> 
>> -----Original Message-----
>> From: Guo, Jia <jia.guo@intel.com>
>> Sent: Wednesday, January 13, 2021 10:05 PM
>> To: Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>;
>> Yang, Qiming <qiming.yang@intel.com>; Wang, Haiyue
>> <haiyue.wang@intel.com>
>> Cc: dev@dpdk.org; Guo, Jia <jia.guo@intel.com>; Su, Simei
>> <simei.su@intel.com>
>> Subject: [dpdk-dev v3 0/3] enable UDP ecpri configure in dcf
>>
>> Enabling ecpri UDP tunnel port configure in dcf.
>>
>> v3:
>> seperate patch set.
>>
>> v2:
>> refactor PTYPE parsing and add related sharecode patch separate patch set
>>
>> Jeff Guo (3):
>>    net/ice: add PTYPE mapping for ecpri
>>    net/iavf: add PTYPE mapping for ecpri
> 
> For patch, 1,2 for new PTYPE mapping.
> 
> Acked-by: Qi Zhang <qi.z.zhang@intel.com>
> 
> Applied to dpdk-next-net-intel.
> 
>>    net/ice: enable ecpri tunnel port configure in dcf
> 
> For patch 3, it is depends on below patches
> 1. enable ecpri tunnel type .
> http://patchwork.dpdk.org/patch/85702/
> 2. refine the description for rte_eth_dev_udp_tunnel_port_add
> http://patchwork.dpdk.org/patch/86406/
> 
> Thomas, Ferruh:
> 	Please let us know if any issue for above patch merge.

First dependency already merged to the next-net and other is a documentation 
patch but still going with the merged patches and will get third patch with this 
set as separate patch.

[dpdk-dev] [dpdk-dev v3 0/2] add new UDP tunnel port for ecpri

[Jeff Guo]

v3:
seperate the patch set and add some document

Jeff Guo (2):
  ethdev: add new tunnel type for ecpri
  app/testpmd: add new UDP tunnel port for ecpri

 app/test-pmd/cmdline.c                      | 9 ++++++---
 doc/guides/rel_notes/release_21_02.rst      | 3 ++-
 doc/guides/testpmd_app_ug/testpmd_funcs.rst | 2 +-
 lib/librte_ethdev/rte_ethdev.h              | 1 +
 4 files changed, 10 insertions(+), 5 deletions(-)

-- 
2.20.1

[dpdk-dev] [dpdk-dev v3 1/2] ethdev: add new tunnel type for ecpri

[Jeff Guo]

Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunnel type.

Signed-off-by: Jeff Guo <jia.guo@intel.com>
Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
 doc/guides/rel_notes/release_21_02.rst | 3 ++-
 lib/librte_ethdev/rte_ethdev.h         | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/doc/guides/rel_notes/release_21_02.rst b/doc/guides/rel_notes/release_21_02.rst
index b1bb2d8679..e5168d1312 100644
--- a/doc/guides/rel_notes/release_21_02.rst
+++ b/doc/guides/rel_notes/release_21_02.rst
@@ -110,7 +110,8 @@ ABI Changes
    Also, make sure to start the actual text at the margin.
    =======================================================
 
-* No ABI change that would break compatibility with 20.11.
+* ethdev: the structure ``rte_eth_tunnel_type`` has added one parameter
+  ``RTE_TUNNEL_TYPE_ECPRI`` for ecpri UDP port configuration.
 
 
 Known Issues
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index f5f8919186..2cbce958cf 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
 	RTE_TUNNEL_TYPE_IP_IN_GRE,
 	RTE_L2_TUNNEL_TYPE_E_TAG,
 	RTE_TUNNEL_TYPE_VXLAN_GPE,
+	RTE_TUNNEL_TYPE_ECPRI,
 	RTE_TUNNEL_TYPE_MAX,
 };
 
-- 
2.20.1

[dpdk-dev] [dpdk-dev v3 2/2] app/testpmd: add new UDP tunnel port for ecpri

[Jeff Guo]

Add new UDP tunnel port params for ecpri configuration, the command
as below:

testpmd> port config 0 udp_tunnel_port add ecpri 6789
testpmd> port config 0 udp_tunnel_port rm ecpri 6789

Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
 app/test-pmd/cmdline.c                      | 9 ++++++---
 doc/guides/testpmd_app_ug/testpmd_funcs.rst | 2 +-
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 2ccbaa039e..596dd239fe 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -845,7 +845,7 @@ static void cmd_help_long_parsed(void *parsed_result,
 			"fdir_inset|fdir_flx_inset clear all"
 			"    Clear RSS|FDIR|FDIR_FLX input set completely for some pctype\n\n"
 
-			"port config (port_id) udp_tunnel_port add|rm vxlan|geneve (udp_port)\n\n"
+			"port config (port_id) udp_tunnel_port add|rm vxlan|geneve|ecpri (udp_port)\n\n"
 			"    Add/remove UDP tunnel port for tunneling offload\n\n"
 
 			"port config <port_id> rx_offload vlan_strip|"
@@ -9175,6 +9175,8 @@ cmd_cfg_tunnel_udp_port_parsed(void *parsed_result,
 		tunnel_udp.prot_type = RTE_TUNNEL_TYPE_GENEVE;
 	} else if (!strcmp(res->tunnel_type, "vxlan-gpe")) {
 		tunnel_udp.prot_type = RTE_TUNNEL_TYPE_VXLAN_GPE;
+	} else if (!strcmp(res->tunnel_type, "ecpri")) {
+		tunnel_udp.prot_type = RTE_TUNNEL_TYPE_ECPRI;
 	} else {
 		printf("Invalid tunnel type\n");
 		return;
@@ -9209,7 +9211,7 @@ cmdline_parse_token_string_t cmd_config_tunnel_udp_port_action =
 				 "add#rm");
 cmdline_parse_token_string_t cmd_config_tunnel_udp_port_tunnel_type =
 	TOKEN_STRING_INITIALIZER(struct cmd_config_tunnel_udp_port, tunnel_type,
-				 "vxlan#geneve#vxlan-gpe");
+				 "vxlan#geneve#vxlan-gpe#ecpri");
 cmdline_parse_token_num_t cmd_config_tunnel_udp_port_value =
 	TOKEN_NUM_INITIALIZER(struct cmd_config_tunnel_udp_port, udp_port,
 			      RTE_UINT16);
@@ -9217,7 +9219,8 @@ cmdline_parse_token_num_t cmd_config_tunnel_udp_port_value =
 cmdline_parse_inst_t cmd_cfg_tunnel_udp_port = {
 	.f = cmd_cfg_tunnel_udp_port_parsed,
 	.data = NULL,
-	.help_str = "port config <port_id> udp_tunnel_port add|rm vxlan|geneve|vxlan-gpe <udp_port>",
+	.help_str = "port config <port_id> udp_tunnel_port add|rm vxlan|"
+		"geneve|vxlan-gpe|ecpri <udp_port>",
 	.tokens = {
 		(void *)&cmd_config_tunnel_udp_port_port,
 		(void *)&cmd_config_tunnel_udp_port_config,
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 9be450066e..842ac42ce6 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -2375,7 +2375,7 @@ port config udp_tunnel_port
 
 Add/remove UDP tunnel port for VXLAN/GENEVE tunneling protocols::
 
-    testpmd> port config (port_id) udp_tunnel_port add|rm vxlan|geneve|vxlan-gpe (udp_port)
+    testpmd> port config (port_id) udp_tunnel_port add|rm vxlan|geneve|vxlan-gpe|ecpri (udp_port)
 
 port config tx_metadata
 ~~~~~~~~~~~~~~~~~~~~~~~
-- 
2.20.1

[dpdk-dev] [dpdk-dev v4 0/2] add new UDP tunnel port configure for eCPRI

[Jeff Guo]

Add new UDP tunnel port configure for eCPRI protocol features

v4:
add doc in release note for all related eCPRI features.

v3:
seperate the patch set and add some document

Jeff Guo (2):
  ethdev: add new tunnel type for eCPRI
  app/testpmd: add new UDP tunnel port for eCPRI

 app/test-pmd/cmdline.c                      |  9 ++++++---
 doc/guides/rel_notes/release_21_02.rst      | 15 ++++++++++++++-
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  2 +-
 lib/librte_ethdev/rte_ethdev.h              |  1 +
 4 files changed, 22 insertions(+), 5 deletions(-)

-- 
2.20.1

[dpdk-dev] [dpdk-dev v4 1/2] ethdev: add new tunnel type for eCPRI

[Jeff Guo]

Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunnel type.

Signed-off-by: Jeff Guo <jia.guo@intel.com>
Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
 doc/guides/rel_notes/release_21_02.rst | 15 ++++++++++++++-
 lib/librte_ethdev/rte_ethdev.h         |  1 +
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/doc/guides/rel_notes/release_21_02.rst b/doc/guides/rel_notes/release_21_02.rst
index b1bb2d8679..2de6afdb85 100644
--- a/doc/guides/rel_notes/release_21_02.rst
+++ b/doc/guides/rel_notes/release_21_02.rst
@@ -61,6 +61,18 @@ New Features
 
   * Added support for Stingray2 device.
 
+* **Updated the Intel ice driver.**
+
+  Updated the Intel ice driver with new features and improvements, including:
+
+  * Added support for UDP dynamic port assignment for eCPRI protocol configure feature. 
+
+* **Updated Intel iavf driver.**
+
+  Updated iavf PMD with new features and improvements, including:
+
+  * Added support for FDIR/RSS packet steering for flow type eCPRI protocol features.
+
 
 Removed Items
 -------------
@@ -110,7 +122,8 @@ ABI Changes
    Also, make sure to start the actual text at the margin.
    =======================================================
 
-* No ABI change that would break compatibility with 20.11.
+* ethdev: the structure ``rte_eth_tunnel_type`` has added one parameter
+  ``RTE_TUNNEL_TYPE_ECPRI`` for eCPRI UDP port configuration.
 
 
 Known Issues
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index f5f8919186..2cbce958cf 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
 	RTE_TUNNEL_TYPE_IP_IN_GRE,
 	RTE_L2_TUNNEL_TYPE_E_TAG,
 	RTE_TUNNEL_TYPE_VXLAN_GPE,
+	RTE_TUNNEL_TYPE_ECPRI,
 	RTE_TUNNEL_TYPE_MAX,
 };
 
-- 
2.20.1

[dpdk-dev] [dpdk-dev v4 2/2] app/testpmd: add new UDP tunnel port for eCPRI

[Jeff Guo]

Add new UDP tunnel port params for eCPRI configuration, the command
as below:

testpmd> port config 0 udp_tunnel_port add ecpri 6789
testpmd> port config 0 udp_tunnel_port rm ecpri 6789

Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
 app/test-pmd/cmdline.c                      | 9 ++++++---
 doc/guides/testpmd_app_ug/testpmd_funcs.rst | 2 +-
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 2ccbaa039e..596dd239fe 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -845,7 +845,7 @@ static void cmd_help_long_parsed(void *parsed_result,
 			"fdir_inset|fdir_flx_inset clear all"
 			"    Clear RSS|FDIR|FDIR_FLX input set completely for some pctype\n\n"
 
-			"port config (port_id) udp_tunnel_port add|rm vxlan|geneve (udp_port)\n\n"
+			"port config (port_id) udp_tunnel_port add|rm vxlan|geneve|ecpri (udp_port)\n\n"
 			"    Add/remove UDP tunnel port for tunneling offload\n\n"
 
 			"port config <port_id> rx_offload vlan_strip|"
@@ -9175,6 +9175,8 @@ cmd_cfg_tunnel_udp_port_parsed(void *parsed_result,
 		tunnel_udp.prot_type = RTE_TUNNEL_TYPE_GENEVE;
 	} else if (!strcmp(res->tunnel_type, "vxlan-gpe")) {
 		tunnel_udp.prot_type = RTE_TUNNEL_TYPE_VXLAN_GPE;
+	} else if (!strcmp(res->tunnel_type, "ecpri")) {
+		tunnel_udp.prot_type = RTE_TUNNEL_TYPE_ECPRI;
 	} else {
 		printf("Invalid tunnel type\n");
 		return;
@@ -9209,7 +9211,7 @@ cmdline_parse_token_string_t cmd_config_tunnel_udp_port_action =
 				 "add#rm");
 cmdline_parse_token_string_t cmd_config_tunnel_udp_port_tunnel_type =
 	TOKEN_STRING_INITIALIZER(struct cmd_config_tunnel_udp_port, tunnel_type,
-				 "vxlan#geneve#vxlan-gpe");
+				 "vxlan#geneve#vxlan-gpe#ecpri");
 cmdline_parse_token_num_t cmd_config_tunnel_udp_port_value =
 	TOKEN_NUM_INITIALIZER(struct cmd_config_tunnel_udp_port, udp_port,
 			      RTE_UINT16);
@@ -9217,7 +9219,8 @@ cmdline_parse_token_num_t cmd_config_tunnel_udp_port_value =
 cmdline_parse_inst_t cmd_cfg_tunnel_udp_port = {
 	.f = cmd_cfg_tunnel_udp_port_parsed,
 	.data = NULL,
-	.help_str = "port config <port_id> udp_tunnel_port add|rm vxlan|geneve|vxlan-gpe <udp_port>",
+	.help_str = "port config <port_id> udp_tunnel_port add|rm vxlan|"
+		"geneve|vxlan-gpe|ecpri <udp_port>",
 	.tokens = {
 		(void *)&cmd_config_tunnel_udp_port_port,
 		(void *)&cmd_config_tunnel_udp_port_config,
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 9be450066e..842ac42ce6 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -2375,7 +2375,7 @@ port config udp_tunnel_port
 
 Add/remove UDP tunnel port for VXLAN/GENEVE tunneling protocols::
 
-    testpmd> port config (port_id) udp_tunnel_port add|rm vxlan|geneve|vxlan-gpe (udp_port)
+    testpmd> port config (port_id) udp_tunnel_port add|rm vxlan|geneve|vxlan-gpe|ecpri (udp_port)
 
 port config tx_metadata
 ~~~~~~~~~~~~~~~~~~~~~~~
-- 
2.20.1

[dpdk-dev] [dpdk-dev v5 0/2] add new UDP tunnel port configure for eCPRI

[Jeff Guo]

Add new UDP tunnel port configure for eCPRI protocol features

v5:
fix a coding style issue.

v4:
add doc in release note for all related eCPRI features.

v3:
seperate the patch set and add some document

Jeff Guo (2):
  ethdev: add new tunnel type for eCPRI
  app/testpmd: add new UDP tunnel port for eCPRI

 app/test-pmd/cmdline.c                      |  9 ++++++---
 doc/guides/rel_notes/release_21_02.rst      | 15 ++++++++++++++-
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  2 +-
 lib/librte_ethdev/rte_ethdev.h              |  1 +
 4 files changed, 22 insertions(+), 5 deletions(-)

-- 
2.20.1

[dpdk-dev] [dpdk-dev v5 1/2] ethdev: add new tunnel type for eCPRI

[Jeff Guo]

Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunnel type.

Signed-off-by: Jeff Guo <jia.guo@intel.com>
Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
 doc/guides/rel_notes/release_21_02.rst | 15 ++++++++++++++-
 lib/librte_ethdev/rte_ethdev.h         |  1 +
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/doc/guides/rel_notes/release_21_02.rst b/doc/guides/rel_notes/release_21_02.rst
index b1bb2d8679..80f71be8e6 100644
--- a/doc/guides/rel_notes/release_21_02.rst
+++ b/doc/guides/rel_notes/release_21_02.rst
@@ -61,6 +61,18 @@ New Features
 
   * Added support for Stingray2 device.
 
+* **Updated the Intel ice driver.**
+
+  Updated the Intel ice driver with new features and improvements, including:
+
+  * Added support for UDP dynamic port assignment for eCPRI protocol configure feature.
+
+* **Updated Intel iavf driver.**
+
+  Updated iavf PMD with new features and improvements, including:
+
+  * Added support for FDIR/RSS packet steering for flow type eCPRI protocol features.
+
 
 Removed Items
 -------------
@@ -110,7 +122,8 @@ ABI Changes
    Also, make sure to start the actual text at the margin.
    =======================================================
 
-* No ABI change that would break compatibility with 20.11.
+* ethdev: the structure ``rte_eth_tunnel_type`` has added one parameter
+  ``RTE_TUNNEL_TYPE_ECPRI`` for eCPRI UDP port configuration.
 
 
 Known Issues
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index f5f8919186..2cbce958cf 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
 	RTE_TUNNEL_TYPE_IP_IN_GRE,
 	RTE_L2_TUNNEL_TYPE_E_TAG,
 	RTE_TUNNEL_TYPE_VXLAN_GPE,
+	RTE_TUNNEL_TYPE_ECPRI,
 	RTE_TUNNEL_TYPE_MAX,
 };
 
-- 
2.20.1

Re: [dpdk-dev] [dpdk-dev v5 1/2] ethdev: add new tunnel type for eCPRI

[Ferruh Yigit]

On 1/15/2021 5:15 AM, Jeff Guo wrote:
> Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunnel type.
> 
> Signed-off-by: Jeff Guo <jia.guo@intel.com>
> Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
> ---
>   doc/guides/rel_notes/release_21_02.rst | 15 ++++++++++++++-
>   lib/librte_ethdev/rte_ethdev.h         |  1 +
>   2 files changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/guides/rel_notes/release_21_02.rst b/doc/guides/rel_notes/release_21_02.rst
> index b1bb2d8679..80f71be8e6 100644
> --- a/doc/guides/rel_notes/release_21_02.rst
> +++ b/doc/guides/rel_notes/release_21_02.rst
> @@ -61,6 +61,18 @@ New Features
>   
>     * Added support for Stingray2 device.
>   
> +* **Updated the Intel ice driver.**
> +
> +  Updated the Intel ice driver with new features and improvements, including:
> +
> +  * Added support for UDP dynamic port assignment for eCPRI protocol configure feature.
> +
> +* **Updated Intel iavf driver.**
> +
> +  Updated iavf PMD with new features and improvements, including:
> +
> +  * Added support for FDIR/RSS packet steering for flow type eCPRI protocol features.
> +

These are not related to the patch, so dropping from the patch.

>   
>   Removed Items
>   -------------
> @@ -110,7 +122,8 @@ ABI Changes
>      Also, make sure to start the actual text at the margin.
>      =======================================================
>   
> -* No ABI change that would break compatibility with 20.11.
> +* ethdev: the structure ``rte_eth_tunnel_type`` has added one parameter
> +  ``RTE_TUNNEL_TYPE_ECPRI`` for eCPRI UDP port configuration.
>   

This is not an ABI break, so should not be in this section, also not an API 
cange, we can't put there too.
And this change is not big enough to add the new features, perhaps better to 
remove this and add the PMD feature updates as you did above for the relevant 
sets, so I am dropping this as well.

>   
>   Known Issues
> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> index f5f8919186..2cbce958cf 100644
> --- a/lib/librte_ethdev/rte_ethdev.h
> +++ b/lib/librte_ethdev/rte_ethdev.h
> @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
>   	RTE_TUNNEL_TYPE_IP_IN_GRE,
>   	RTE_L2_TUNNEL_TYPE_E_TAG,
>   	RTE_TUNNEL_TYPE_VXLAN_GPE,
> +	RTE_TUNNEL_TYPE_ECPRI,
>   	RTE_TUNNEL_TYPE_MAX,
>   };
>   
> 

Re: [dpdk-dev] [dpdk-dev v5 1/2] ethdev: add new tunnel type for eCPRI

[Guo, Jia]

> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Friday, January 15, 2021 8:23 PM
> To: Guo, Jia <jia.guo@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>;
> thomas@monjalon.net; andrew.rybchenko@oktetlabs.ru; Iremonger,
> Bernard <bernard.iremonger@intel.com>; Lu, Wenzhuo
> <wenzhuo.lu@intel.com>; Xing, Beilei <beilei.xing@intel.com>
> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
> <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
> dev@dpdk.org; Su, Simei <simei.su@intel.com>; orika@nvidia.com;
> getelson@nvidia.com; maxime.coquelin@redhat.com; jerinj@marvell.com;
> ajit.khaparde@broadcom.com; bingz@nvidia.com; Kinsella, Ray
> <ray.kinsella@intel.com>; dodji@redhat.com; david.marchand@redhat.com
> Subject: Re: [dpdk-dev v5 1/2] ethdev: add new tunnel type for eCPRI
> 
> On 1/15/2021 5:15 AM, Jeff Guo wrote:
> > Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunnel
> type.
> >
> > Signed-off-by: Jeff Guo <jia.guo@intel.com>
> > Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
> > Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
> > ---
> >   doc/guides/rel_notes/release_21_02.rst | 15 ++++++++++++++-
> >   lib/librte_ethdev/rte_ethdev.h         |  1 +
> >   2 files changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/guides/rel_notes/release_21_02.rst
> > b/doc/guides/rel_notes/release_21_02.rst
> > index b1bb2d8679..80f71be8e6 100644
> > --- a/doc/guides/rel_notes/release_21_02.rst
> > +++ b/doc/guides/rel_notes/release_21_02.rst
> > @@ -61,6 +61,18 @@ New Features
> >
> >     * Added support for Stingray2 device.
> >
> > +* **Updated the Intel ice driver.**
> > +
> > +  Updated the Intel ice driver with new features and improvements,
> including:
> > +
> > +  * Added support for UDP dynamic port assignment for eCPRI protocol
> configure feature.
> > +
> > +* **Updated Intel iavf driver.**
> > +
> > +  Updated iavf PMD with new features and improvements, including:
> > +
> > +  * Added support for FDIR/RSS packet steering for flow type eCPRI
> protocol features.
> > +
> 
> These are not related to the patch, so dropping from the patch.
> 

Ok.

> >
> >   Removed Items
> >   -------------
> > @@ -110,7 +122,8 @@ ABI Changes
> >      Also, make sure to start the actual text at the margin.
> >      =======================================================
> >
> > -* No ABI change that would break compatibility with 20.11.
> > +* ethdev: the structure ``rte_eth_tunnel_type`` has added one
> > +parameter
> > +  ``RTE_TUNNEL_TYPE_ECPRI`` for eCPRI UDP port configuration.
> >
> 
> This is not an ABI break, so should not be in this section, also not an API cange,
> we can't put there too.
> And this change is not big enough to add the new features, perhaps better to
> remove this and add the PMD feature updates as you did above for the
> relevant sets, so I am dropping this as well.
> 

Ok, I will use another coming patch to update the doc. Thanks.

> >
> >   Known Issues
> > diff --git a/lib/librte_ethdev/rte_ethdev.h
> > b/lib/librte_ethdev/rte_ethdev.h index f5f8919186..2cbce958cf 100644
> > --- a/lib/librte_ethdev/rte_ethdev.h
> > +++ b/lib/librte_ethdev/rte_ethdev.h
> > @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
> >   	RTE_TUNNEL_TYPE_IP_IN_GRE,
> >   	RTE_L2_TUNNEL_TYPE_E_TAG,
> >   	RTE_TUNNEL_TYPE_VXLAN_GPE,
> > +	RTE_TUNNEL_TYPE_ECPRI,
> >   	RTE_TUNNEL_TYPE_MAX,
> >   };
> >
> >

[dpdk-dev] [dpdk-dev v5 2/2] app/testpmd: add new UDP tunnel port for eCPRI

[Jeff Guo]

Add new UDP tunnel port params for eCPRI configuration, the command
as below:

testpmd> port config 0 udp_tunnel_port add ecpri 6789
testpmd> port config 0 udp_tunnel_port rm ecpri 6789

Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
 app/test-pmd/cmdline.c                      | 9 ++++++---
 doc/guides/testpmd_app_ug/testpmd_funcs.rst | 2 +-
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 2ccbaa039e..596dd239fe 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -845,7 +845,7 @@ static void cmd_help_long_parsed(void *parsed_result,
 			"fdir_inset|fdir_flx_inset clear all"
 			"    Clear RSS|FDIR|FDIR_FLX input set completely for some pctype\n\n"
 
-			"port config (port_id) udp_tunnel_port add|rm vxlan|geneve (udp_port)\n\n"
+			"port config (port_id) udp_tunnel_port add|rm vxlan|geneve|ecpri (udp_port)\n\n"
 			"    Add/remove UDP tunnel port for tunneling offload\n\n"
 
 			"port config <port_id> rx_offload vlan_strip|"
@@ -9175,6 +9175,8 @@ cmd_cfg_tunnel_udp_port_parsed(void *parsed_result,
 		tunnel_udp.prot_type = RTE_TUNNEL_TYPE_GENEVE;
 	} else if (!strcmp(res->tunnel_type, "vxlan-gpe")) {
 		tunnel_udp.prot_type = RTE_TUNNEL_TYPE_VXLAN_GPE;
+	} else if (!strcmp(res->tunnel_type, "ecpri")) {
+		tunnel_udp.prot_type = RTE_TUNNEL_TYPE_ECPRI;
 	} else {
 		printf("Invalid tunnel type\n");
 		return;
@@ -9209,7 +9211,7 @@ cmdline_parse_token_string_t cmd_config_tunnel_udp_port_action =
 				 "add#rm");
 cmdline_parse_token_string_t cmd_config_tunnel_udp_port_tunnel_type =
 	TOKEN_STRING_INITIALIZER(struct cmd_config_tunnel_udp_port, tunnel_type,
-				 "vxlan#geneve#vxlan-gpe");
+				 "vxlan#geneve#vxlan-gpe#ecpri");
 cmdline_parse_token_num_t cmd_config_tunnel_udp_port_value =
 	TOKEN_NUM_INITIALIZER(struct cmd_config_tunnel_udp_port, udp_port,
 			      RTE_UINT16);
@@ -9217,7 +9219,8 @@ cmdline_parse_token_num_t cmd_config_tunnel_udp_port_value =
 cmdline_parse_inst_t cmd_cfg_tunnel_udp_port = {
 	.f = cmd_cfg_tunnel_udp_port_parsed,
 	.data = NULL,
-	.help_str = "port config <port_id> udp_tunnel_port add|rm vxlan|geneve|vxlan-gpe <udp_port>",
+	.help_str = "port config <port_id> udp_tunnel_port add|rm vxlan|"
+		"geneve|vxlan-gpe|ecpri <udp_port>",
 	.tokens = {
 		(void *)&cmd_config_tunnel_udp_port_port,
 		(void *)&cmd_config_tunnel_udp_port_config,
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 9be450066e..842ac42ce6 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -2375,7 +2375,7 @@ port config udp_tunnel_port
 
 Add/remove UDP tunnel port for VXLAN/GENEVE tunneling protocols::
 
-    testpmd> port config (port_id) udp_tunnel_port add|rm vxlan|geneve|vxlan-gpe (udp_port)
+    testpmd> port config (port_id) udp_tunnel_port add|rm vxlan|geneve|vxlan-gpe|ecpri (udp_port)
 
 port config tx_metadata
 ~~~~~~~~~~~~~~~~~~~~~~~
-- 
2.20.1

Re: [dpdk-dev] [dpdk-dev v5 2/2] app/testpmd: add new UDP tunnel port for eCPRI

[Ferruh Yigit]

On 1/15/2021 5:15 AM, Jeff Guo wrote:
> Add new UDP tunnel port params for eCPRI configuration, the command
> as below:
> 
> testpmd> port config 0 udp_tunnel_port add ecpri 6789
> testpmd> port config 0 udp_tunnel_port rm ecpri 6789
> 
> Signed-off-by: Jeff Guo <jia.guo@intel.com>

Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>

Re: [dpdk-dev] [dpdk-dev v5 0/2] add new UDP tunnel port configure for eCPRI

[Ferruh Yigit]

On 1/15/2021 5:15 AM, Jeff Guo wrote:
> Add new UDP tunnel port configure for eCPRI protocol features
> 
> v5:
> fix a coding style issue.
> 
> v4:
> add doc in release note for all related eCPRI features.
> 
> v3:
> seperate the patch set and add some document
> 
> Jeff Guo (2):
>    ethdev: add new tunnel type for eCPRI
>    app/testpmd: add new UDP tunnel port for eCPRI
> 

Series applied to dpdk-next-net/main, thanks.

[dpdk-dev] [dpdk-dev v4] net/ice: enable eCPRI tunnel port configure in dcf

[Jeff Guo]

Add eCPRI tunnel port add and rm ops to configure eCPRI UDP tunnel port
in dcf.

Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
 doc/guides/rel_notes/release_21_02.rst | 12 +++++
 drivers/net/ice/ice_dcf_ethdev.c       | 67 ++++++++++++++++++++++++++
 2 files changed, 79 insertions(+)

diff --git a/doc/guides/rel_notes/release_21_02.rst b/doc/guides/rel_notes/release_21_02.rst
index 3bb0b9a9ed..c84f0bfad9 100644
--- a/doc/guides/rel_notes/release_21_02.rst
+++ b/doc/guides/rel_notes/release_21_02.rst
@@ -72,6 +72,18 @@ New Features
 
   * Added inner UDP/IPv4 support for VXLAN IPv4 GSO.
 
+* **Updated the Intel ice driver.**
+
+  Updated the Intel ice driver with new features and improvements, including:
+
+  * Added support for UDP dynamic port assignment for eCPRI protocol feature.
+
+* **Updated Intel iavf driver.**
+
+  Updated iavf PMD with new features and improvements, including:
+
+  * Added support for FDIR/RSS packet steering for flow type eCPRI protocol features.
+
 
 Removed Items
 -------------
diff --git a/drivers/net/ice/ice_dcf_ethdev.c b/drivers/net/ice/ice_dcf_ethdev.c
index a9e78064d4..c8357f5054 100644
--- a/drivers/net/ice/ice_dcf_ethdev.c
+++ b/drivers/net/ice/ice_dcf_ethdev.c
@@ -26,6 +26,13 @@
 #include "ice_dcf_ethdev.h"
 #include "ice_rxtx.h"
 
+static int
+ice_dcf_dev_udp_tunnel_port_add(struct rte_eth_dev *dev,
+				struct rte_eth_udp_tunnel *udp_tunnel);
+static int
+ice_dcf_dev_udp_tunnel_port_del(struct rte_eth_dev *dev,
+				struct rte_eth_udp_tunnel *udp_tunnel);
+
 static uint16_t
 ice_dcf_recv_pkts(__rte_unused void *rx_queue,
 		  __rte_unused struct rte_mbuf **bufs,
@@ -870,6 +877,64 @@ ice_dcf_link_update(__rte_unused struct rte_eth_dev *dev,
 	return 0;
 }
 
+/* Add UDP tunneling port */
+static int
+ice_dcf_dev_udp_tunnel_port_add(struct rte_eth_dev *dev,
+				struct rte_eth_udp_tunnel *udp_tunnel)
+{
+	struct ice_dcf_adapter *adapter = dev->data->dev_private;
+	struct ice_adapter *parent_adapter = &adapter->parent;
+	struct ice_hw *parent_hw = &parent_adapter->hw;
+	int ret = 0;
+
+	if (!udp_tunnel)
+		return -EINVAL;
+
+	switch (udp_tunnel->prot_type) {
+	case RTE_TUNNEL_TYPE_VXLAN:
+		ret = ice_create_tunnel(parent_hw, TNL_VXLAN,
+					udp_tunnel->udp_port);
+		break;
+	case RTE_TUNNEL_TYPE_ECPRI:
+		ret = ice_create_tunnel(parent_hw, TNL_ECPRI,
+					udp_tunnel->udp_port);
+		break;
+	default:
+		PMD_DRV_LOG(ERR, "Invalid tunnel type");
+		ret = -EINVAL;
+		break;
+	}
+
+	return ret;
+}
+
+/* Delete UDP tunneling port */
+static int
+ice_dcf_dev_udp_tunnel_port_del(struct rte_eth_dev *dev,
+				struct rte_eth_udp_tunnel *udp_tunnel)
+{
+	struct ice_dcf_adapter *adapter = dev->data->dev_private;
+	struct ice_adapter *parent_adapter = &adapter->parent;
+	struct ice_hw *parent_hw = &parent_adapter->hw;
+	int ret = 0;
+
+	if (!udp_tunnel)
+		return -EINVAL;
+
+	switch (udp_tunnel->prot_type) {
+	case RTE_TUNNEL_TYPE_VXLAN:
+	case RTE_TUNNEL_TYPE_ECPRI:
+		ret = ice_destroy_tunnel(parent_hw, udp_tunnel->udp_port, 0);
+		break;
+	default:
+		PMD_DRV_LOG(ERR, "Invalid tunnel type");
+		ret = -EINVAL;
+		break;
+	}
+
+	return ret;
+}
+
 static const struct eth_dev_ops ice_dcf_eth_dev_ops = {
 	.dev_start               = ice_dcf_dev_start,
 	.dev_stop                = ice_dcf_dev_stop,
@@ -892,6 +957,8 @@ static const struct eth_dev_ops ice_dcf_eth_dev_ops = {
 	.allmulticast_enable     = ice_dcf_dev_allmulticast_enable,
 	.allmulticast_disable    = ice_dcf_dev_allmulticast_disable,
 	.filter_ctrl             = ice_dcf_dev_filter_ctrl,
+	.udp_tunnel_port_add	 = ice_dcf_dev_udp_tunnel_port_add,
+	.udp_tunnel_port_del	 = ice_dcf_dev_udp_tunnel_port_del,
 };
 
 static int
-- 
2.20.1

[dpdk-dev] [dpdk-dev v4] net/ice: enable eCPRI tunnel port configure in dcf

[Jeff Guo]

Add eCPRI tunnel port add and rm ops to configure eCPRI UDP tunnel port
in dcf.

Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
 doc/guides/rel_notes/release_21_02.rst | 12 +++++
 drivers/net/ice/ice_dcf_ethdev.c       | 67 ++++++++++++++++++++++++++
 2 files changed, 79 insertions(+)

diff --git a/doc/guides/rel_notes/release_21_02.rst b/doc/guides/rel_notes/release_21_02.rst
index 3bb0b9a9ed..c84f0bfad9 100644
--- a/doc/guides/rel_notes/release_21_02.rst
+++ b/doc/guides/rel_notes/release_21_02.rst
@@ -72,6 +72,18 @@ New Features
 
   * Added inner UDP/IPv4 support for VXLAN IPv4 GSO.
 
+* **Updated the Intel ice driver.**
+
+  Updated the Intel ice driver with new features and improvements, including:
+
+  * Added support for UDP dynamic port assignment for eCPRI protocol feature.
+
+* **Updated Intel iavf driver.**
+
+  Updated iavf PMD with new features and improvements, including:
+
+  * Added support for FDIR/RSS packet steering for flow type eCPRI protocol features.
+
 
 Removed Items
 -------------
diff --git a/drivers/net/ice/ice_dcf_ethdev.c b/drivers/net/ice/ice_dcf_ethdev.c
index a9e78064d4..c8357f5054 100644
--- a/drivers/net/ice/ice_dcf_ethdev.c
+++ b/drivers/net/ice/ice_dcf_ethdev.c
@@ -26,6 +26,13 @@
 #include "ice_dcf_ethdev.h"
 #include "ice_rxtx.h"
 
+static int
+ice_dcf_dev_udp_tunnel_port_add(struct rte_eth_dev *dev,
+				struct rte_eth_udp_tunnel *udp_tunnel);
+static int
+ice_dcf_dev_udp_tunnel_port_del(struct rte_eth_dev *dev,
+				struct rte_eth_udp_tunnel *udp_tunnel);
+
 static uint16_t
 ice_dcf_recv_pkts(__rte_unused void *rx_queue,
 		  __rte_unused struct rte_mbuf **bufs,
@@ -870,6 +877,64 @@ ice_dcf_link_update(__rte_unused struct rte_eth_dev *dev,
 	return 0;
 }
 
+/* Add UDP tunneling port */
+static int
+ice_dcf_dev_udp_tunnel_port_add(struct rte_eth_dev *dev,
+				struct rte_eth_udp_tunnel *udp_tunnel)
+{
+	struct ice_dcf_adapter *adapter = dev->data->dev_private;
+	struct ice_adapter *parent_adapter = &adapter->parent;
+	struct ice_hw *parent_hw = &parent_adapter->hw;
+	int ret = 0;
+
+	if (!udp_tunnel)
+		return -EINVAL;
+
+	switch (udp_tunnel->prot_type) {
+	case RTE_TUNNEL_TYPE_VXLAN:
+		ret = ice_create_tunnel(parent_hw, TNL_VXLAN,
+					udp_tunnel->udp_port);
+		break;
+	case RTE_TUNNEL_TYPE_ECPRI:
+		ret = ice_create_tunnel(parent_hw, TNL_ECPRI,
+					udp_tunnel->udp_port);
+		break;
+	default:
+		PMD_DRV_LOG(ERR, "Invalid tunnel type");
+		ret = -EINVAL;
+		break;
+	}
+
+	return ret;
+}
+
+/* Delete UDP tunneling port */
+static int
+ice_dcf_dev_udp_tunnel_port_del(struct rte_eth_dev *dev,
+				struct rte_eth_udp_tunnel *udp_tunnel)
+{
+	struct ice_dcf_adapter *adapter = dev->data->dev_private;
+	struct ice_adapter *parent_adapter = &adapter->parent;
+	struct ice_hw *parent_hw = &parent_adapter->hw;
+	int ret = 0;
+
+	if (!udp_tunnel)
+		return -EINVAL;
+
+	switch (udp_tunnel->prot_type) {
+	case RTE_TUNNEL_TYPE_VXLAN:
+	case RTE_TUNNEL_TYPE_ECPRI:
+		ret = ice_destroy_tunnel(parent_hw, udp_tunnel->udp_port, 0);
+		break;
+	default:
+		PMD_DRV_LOG(ERR, "Invalid tunnel type");
+		ret = -EINVAL;
+		break;
+	}
+
+	return ret;
+}
+
 static const struct eth_dev_ops ice_dcf_eth_dev_ops = {
 	.dev_start               = ice_dcf_dev_start,
 	.dev_stop                = ice_dcf_dev_stop,
@@ -892,6 +957,8 @@ static const struct eth_dev_ops ice_dcf_eth_dev_ops = {
 	.allmulticast_enable     = ice_dcf_dev_allmulticast_enable,
 	.allmulticast_disable    = ice_dcf_dev_allmulticast_disable,
 	.filter_ctrl             = ice_dcf_dev_filter_ctrl,
+	.udp_tunnel_port_add	 = ice_dcf_dev_udp_tunnel_port_add,
+	.udp_tunnel_port_del	 = ice_dcf_dev_udp_tunnel_port_del,
 };
 
 static int
-- 
2.20.1

[dpdk-dev] [dpdk-dev v5] net/ice: enable eCPRI tunnel port configure in dcf

[Jeff Guo]

Add eCPRI tunnel port add and rm ops to configure eCPRI UDP tunnel port
in dcf.

Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
v5:
rebase patch

v4:
add doc
---
 doc/guides/rel_notes/release_21_02.rst | 12 +++++
 drivers/net/ice/ice_dcf_ethdev.c       | 67 ++++++++++++++++++++++++++
 2 files changed, 79 insertions(+)

diff --git a/doc/guides/rel_notes/release_21_02.rst b/doc/guides/rel_notes/release_21_02.rst
index 78ec2758e2..6b7870779f 100644
--- a/doc/guides/rel_notes/release_21_02.rst
+++ b/doc/guides/rel_notes/release_21_02.rst
@@ -106,6 +106,18 @@ New Features
 
   * Added Double VLAN support for DCF switch QinQ filtering.
 
+* **Updated the Intel ice driver.**
+
+  Updated the Intel ice driver with new features and improvements, including:
+
+  * Added support for UDP dynamic port assignment for eCPRI protocol feature.
+
+* **Updated Intel iavf driver.**
+
+  Updated iavf PMD with new features and improvements, including:
+
+  * Added support for FDIR/RSS packet steering for flow type eCPRI protocol features.
+
 
 Removed Items
 -------------
diff --git a/drivers/net/ice/ice_dcf_ethdev.c b/drivers/net/ice/ice_dcf_ethdev.c
index d46734a57b..04e42d322a 100644
--- a/drivers/net/ice/ice_dcf_ethdev.c
+++ b/drivers/net/ice/ice_dcf_ethdev.c
@@ -26,6 +26,13 @@
 #include "ice_dcf_ethdev.h"
 #include "ice_rxtx.h"
 
+static int
+ice_dcf_dev_udp_tunnel_port_add(struct rte_eth_dev *dev,
+				struct rte_eth_udp_tunnel *udp_tunnel);
+static int
+ice_dcf_dev_udp_tunnel_port_del(struct rte_eth_dev *dev,
+				struct rte_eth_udp_tunnel *udp_tunnel);
+
 static uint16_t
 ice_dcf_recv_pkts(__rte_unused void *rx_queue,
 		  __rte_unused struct rte_mbuf **bufs,
@@ -870,6 +877,64 @@ ice_dcf_link_update(__rte_unused struct rte_eth_dev *dev,
 	return 0;
 }
 
+/* Add UDP tunneling port */
+static int
+ice_dcf_dev_udp_tunnel_port_add(struct rte_eth_dev *dev,
+				struct rte_eth_udp_tunnel *udp_tunnel)
+{
+	struct ice_dcf_adapter *adapter = dev->data->dev_private;
+	struct ice_adapter *parent_adapter = &adapter->parent;
+	struct ice_hw *parent_hw = &parent_adapter->hw;
+	int ret = 0;
+
+	if (!udp_tunnel)
+		return -EINVAL;
+
+	switch (udp_tunnel->prot_type) {
+	case RTE_TUNNEL_TYPE_VXLAN:
+		ret = ice_create_tunnel(parent_hw, TNL_VXLAN,
+					udp_tunnel->udp_port);
+		break;
+	case RTE_TUNNEL_TYPE_ECPRI:
+		ret = ice_create_tunnel(parent_hw, TNL_ECPRI,
+					udp_tunnel->udp_port);
+		break;
+	default:
+		PMD_DRV_LOG(ERR, "Invalid tunnel type");
+		ret = -EINVAL;
+		break;
+	}
+
+	return ret;
+}
+
+/* Delete UDP tunneling port */
+static int
+ice_dcf_dev_udp_tunnel_port_del(struct rte_eth_dev *dev,
+				struct rte_eth_udp_tunnel *udp_tunnel)
+{
+	struct ice_dcf_adapter *adapter = dev->data->dev_private;
+	struct ice_adapter *parent_adapter = &adapter->parent;
+	struct ice_hw *parent_hw = &parent_adapter->hw;
+	int ret = 0;
+
+	if (!udp_tunnel)
+		return -EINVAL;
+
+	switch (udp_tunnel->prot_type) {
+	case RTE_TUNNEL_TYPE_VXLAN:
+	case RTE_TUNNEL_TYPE_ECPRI:
+		ret = ice_destroy_tunnel(parent_hw, udp_tunnel->udp_port, 0);
+		break;
+	default:
+		PMD_DRV_LOG(ERR, "Invalid tunnel type");
+		ret = -EINVAL;
+		break;
+	}
+
+	return ret;
+}
+
 static const struct eth_dev_ops ice_dcf_eth_dev_ops = {
 	.dev_start               = ice_dcf_dev_start,
 	.dev_stop                = ice_dcf_dev_stop,
@@ -892,6 +957,8 @@ static const struct eth_dev_ops ice_dcf_eth_dev_ops = {
 	.allmulticast_enable     = ice_dcf_dev_allmulticast_enable,
 	.allmulticast_disable    = ice_dcf_dev_allmulticast_disable,
 	.filter_ctrl             = ice_dcf_dev_filter_ctrl,
+	.udp_tunnel_port_add	 = ice_dcf_dev_udp_tunnel_port_add,
+	.udp_tunnel_port_del	 = ice_dcf_dev_udp_tunnel_port_del,
 };
 
 static int
-- 
2.20.1

Re: [dpdk-dev] [dpdk-dev v5] net/ice: enable eCPRI tunnel port configure in dcf

[Zhang, Qi Z]

> -----Original Message-----
> From: Guo, Jia <jia.guo@intel.com>
> Sent: Tuesday, January 19, 2021 12:19 PM
> To: Zhang, Qi Z <qi.z.zhang@intel.com>; thomas@monjalon.net; Yigit, Ferruh
> <ferruh.yigit@intel.com>; andrew.rybchenko@oktetlabs.ru; Iremonger, Bernard
> <bernard.iremonger@intel.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Xing,
> Beilei <beilei.xing@intel.com>
> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
> <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
> dev@dpdk.org; Guo, Jia <jia.guo@intel.com>; Su, Simei <simei.su@intel.com>;
> orika@nvidia.com; getelson@nvidia.com; maxime.coquelin@redhat.com;
> jerinj@marvell.com; ajit.khaparde@broadcom.com; bingz@nvidia.com; Kinsella,
> Ray <ray.kinsella@intel.com>; dodji@redhat.com; david.marchand@redhat.com
> Subject: [dpdk-dev v5] net/ice: enable eCPRI tunnel port configure in dcf
> 
> Add eCPRI tunnel port add and rm ops to configure eCPRI UDP tunnel port in dcf.
> 
> Signed-off-by: Jeff Guo <jia.guo@intel.com>
> ---
> v5:
> rebase patch
> 
> v4:
> add doc
> ---
>  doc/guides/rel_notes/release_21_02.rst | 12 +++++
>  drivers/net/ice/ice_dcf_ethdev.c       | 67 ++++++++++++++++++++++++++
>  2 files changed, 79 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/release_21_02.rst
> b/doc/guides/rel_notes/release_21_02.rst
> index 78ec2758e2..6b7870779f 100644
> --- a/doc/guides/rel_notes/release_21_02.rst
> +++ b/doc/guides/rel_notes/release_21_02.rst
> @@ -106,6 +106,18 @@ New Features
> 
>    * Added Double VLAN support for DCF switch QinQ filtering.
> 
> +* **Updated the Intel ice driver.**
> +
> +  Updated the Intel ice driver with new features and improvements, including:
> +
> +  * Added support for UDP dynamic port assignment for eCPRI protocol
> feature.

Need to claim this is a feature for ice DCF, reword to

Added support for UDP dynamic port assignment for eCPRI tunnel in DCF.

Acked-by: Qi Zhang <qi.z.zhang@intel.com>

Applied to dpdk-next-net-intel.

Thanks
Qi

Re: [dpdk-dev] [dpdk-dev v5] net/ice: enable eCPRI tunnel port configure in dcf

[Thomas Monjalon]

20/01/2021 11:14, Zhang, Qi Z:
> From: Guo, Jia <jia.guo@intel.com>
> > +  * Added support for UDP dynamic port assignment for eCPRI protocol
> > feature.
> 
> Need to claim this is a feature for ice DCF

What is DCF?

Re: [dpdk-dev] [dpdk-dev v5] net/ice: enable eCPRI tunnel port configure in dcf

[Zhang, Qi Z]

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Wednesday, January 20, 2021 6:20 PM
> To: Guo, Jia <jia.guo@intel.com>; Yigit, Ferruh <ferruh.yigit@intel.com>; Lu,
> Wenzhuo <wenzhuo.lu@intel.com>; Xing, Beilei <beilei.xing@intel.com>; Zhang,
> Qi Z <qi.z.zhang@intel.com>
> Cc: andrew.rybchenko@oktetlabs.ru; Iremonger, Bernard
> <bernard.iremonger@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>; Yang,
> Qiming <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
> dev@dpdk.org; Su, Simei <simei.su@intel.com>; orika@nvidia.com;
> getelson@nvidia.com; maxime.coquelin@redhat.com; jerinj@marvell.com;
> ajit.khaparde@broadcom.com; bingz@nvidia.com; Kinsella, Ray
> <ray.kinsella@intel.com>; dodji@redhat.com; david.marchand@redhat.com
> Subject: Re: [dpdk-dev v5] net/ice: enable eCPRI tunnel port configure in dcf
> 
> 20/01/2021 11:14, Zhang, Qi Z:
> > From: Guo, Jia <jia.guo@intel.com>
> > > +  * Added support for UDP dynamic port assignment for eCPRI protocol
> > > feature.
> >
> > Need to claim this is a feature for ice DCF
> 
> What is DCF?
> 
> 
Its "Device Config Function" (DCF), please check ice.rst for detail.

Regards
Qi

Re: [dpdk-dev] [dpdk-dev v5] net/ice: enable eCPRI tunnel port configure in dcf

[Thomas Monjalon]

20/01/2021 11:23, Zhang, Qi Z:
> From: Thomas Monjalon <thomas@monjalon.net>
> > What is DCF?
> > 
> > 
> Its "Device Config Function" (DCF), please check ice.rst for detail.

Thank you.
As you know, I am interested in the privileged rights.
This is what I found in ice.rst:

	A DCF PMD bounds to the device's trusted VF with ID 0
	[...]
	#. Enable the VF0 trust on::
	   ip link set dev enp24s0f0 vf 0 trust on

Does it mean only VF 0 can be trusted?

Re: [dpdk-dev] [dpdk-dev v5] net/ice: enable eCPRI tunnel port configure in dcf

[Zhang, Qi Z]

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Wednesday, January 20, 2021 6:31 PM
> To: Guo, Jia <jia.guo@intel.com>; Yigit, Ferruh <ferruh.yigit@intel.com>; Lu,
> Wenzhuo <wenzhuo.lu@intel.com>; Xing, Beilei <beilei.xing@intel.com>; Zhang,
> Qi Z <qi.z.zhang@intel.com>
> Cc: andrew.rybchenko@oktetlabs.ru; Iremonger, Bernard
> <bernard.iremonger@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>; Yang,
> Qiming <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
> dev@dpdk.org; Su, Simei <simei.su@intel.com>; orika@nvidia.com;
> getelson@nvidia.com; maxime.coquelin@redhat.com; jerinj@marvell.com;
> ajit.khaparde@broadcom.com; bingz@nvidia.com; Kinsella, Ray
> <ray.kinsella@intel.com>; dodji@redhat.com; david.marchand@redhat.com
> Subject: Re: [dpdk-dev v5] net/ice: enable eCPRI tunnel port configure in dcf
> 
> 20/01/2021 11:23, Zhang, Qi Z:
> > From: Thomas Monjalon <thomas@monjalon.net>
> > > What is DCF?
> > >
> > >
> > Its "Device Config Function" (DCF), please check ice.rst for detail.
> 
> Thank you.
> As you know, I am interested in the privileged rights.
> This is what I found in ice.rst:
> 
> 	A DCF PMD bounds to the device's trusted VF with ID 0
> 	[...]
> 	#. Enable the VF0 trust on::
> 	   ip link set dev enp24s0f0 vf 0 trust on
> 
> Does it mean only VF 0 can be trusted?

Yes, currently we only allow VF0 have DCF capability, but that limitation might be removed at some time.
> 

Re: [dpdk-dev] [dpdk-dev v5] net/ice: enable eCPRI tunnel port configure in dcf

[Thomas Monjalon]

20/01/2021 11:36, Zhang, Qi Z:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 20/01/2021 11:23, Zhang, Qi Z:
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > What is DCF?
> > > >
> > > >
> > > Its "Device Config Function" (DCF), please check ice.rst for detail.
> > 
> > Thank you.
> > As you know, I am interested in the privileged rights.
> > This is what I found in ice.rst:
> > 
> > 	A DCF PMD bounds to the device's trusted VF with ID 0
> > 	[...]
> > 	#. Enable the VF0 trust on::
> > 	   ip link set dev enp24s0f0 vf 0 trust on
> > 
> > Does it mean only VF 0 can be trusted?
> 
> Yes, currently we only allow VF0 have DCF capability, but that limitation might be removed at some time.

OK thanks for the explanations.