patches for DPDK stable branches
 help / color / mirror / Atom feed
* [PATCH 1/5] net/mlx5: fix VXLAN-GPE next protocol translation
@ 2021-11-14 15:36 Gregory Etelson
  2021-11-14 15:36 ` [PATCH 2/5] net/mlx5: add Ethernet header to GENEVE RSS expansion Gregory Etelson
                   ` (5 more replies)
  0 siblings, 6 replies; 11+ messages in thread
From: Gregory Etelson @ 2021-11-14 15:36 UTC (permalink / raw)
  To: dev, getelson
  Cc: matan, rasland, stable, Viacheslav Ovsiienko, Raslan Darawsheh

VXLAN-GPE extends VXLAN protocol and provides the next protocol
field specifying the first inner header type.

The application can assign some explicit value to
VXLAN-GPE::next_protocol field or set it to the default one. In the
latter case, the rdma-core library cannot recognize the matcher
built by PMD correctly, and it results in hardware configuration
missing inner headers match.

The patch forces VXLAN-GPE::next_protocol assignment if the
application did not explicitly assign it to the non-default value

Cc: stable@dpdk.org

Fixes: 90456726eb80 ("net/mlx5: fix VXLAN-GPE item translation")
Signed-off-by: Gregory Etelson <getelson@nvidia.com>
---
 drivers/net/mlx5/mlx5_flow_dv.c | 76 ++++++++++++++++++---------------
 1 file changed, 42 insertions(+), 34 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 1b4e15dff1..f9acb69cca 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -8962,46 +8962,40 @@ flow_dv_translate_item_vxlan(struct rte_eth_dev *dev,
 
 static void
 flow_dv_translate_item_vxlan_gpe(void *matcher, void *key,
-				 const struct rte_flow_item *item, int inner)
+				 const struct rte_flow_item *item,
+				 const uint64_t pattern_flags)
 {
+	static const struct rte_flow_item_vxlan_gpe dummy_vxlan_gpe_hdr = {0, };
 	const struct rte_flow_item_vxlan_gpe *vxlan_m = item->mask;
 	const struct rte_flow_item_vxlan_gpe *vxlan_v = item->spec;
-	void *headers_m;
-	void *headers_v;
+	/* The item was validated to be on the outer side */
+	void *headers_m = MLX5_ADDR_OF(fte_match_param, matcher, outer_headers);
+	void *headers_v = MLX5_ADDR_OF(fte_match_param, key, outer_headers);
 	void *misc_m =
 		MLX5_ADDR_OF(fte_match_param, matcher, misc_parameters_3);
 	void *misc_v =
 		MLX5_ADDR_OF(fte_match_param, key, misc_parameters_3);
-	char *vni_m;
-	char *vni_v;
-	uint16_t dport;
-	int size;
-	int i;
+	char *vni_m =
+		MLX5_ADDR_OF(fte_match_set_misc3, misc_m, outer_vxlan_gpe_vni);
+	char *vni_v =
+		MLX5_ADDR_OF(fte_match_set_misc3, misc_v, outer_vxlan_gpe_vni);
+	int i, size = sizeof(vxlan_m->vni);
 	uint8_t flags_m = 0xff;
 	uint8_t flags_v = 0xc;
+	uint8_t m_protocol, v_protocol;
 
-	if (inner) {
-		headers_m = MLX5_ADDR_OF(fte_match_param, matcher,
-					 inner_headers);
-		headers_v = MLX5_ADDR_OF(fte_match_param, key, inner_headers);
-	} else {
-		headers_m = MLX5_ADDR_OF(fte_match_param, matcher,
-					 outer_headers);
-		headers_v = MLX5_ADDR_OF(fte_match_param, key, outer_headers);
-	}
-	dport = item->type == RTE_FLOW_ITEM_TYPE_VXLAN ?
-		MLX5_UDP_PORT_VXLAN : MLX5_UDP_PORT_VXLAN_GPE;
 	if (!MLX5_GET16(fte_match_set_lyr_2_4, headers_v, udp_dport)) {
 		MLX5_SET(fte_match_set_lyr_2_4, headers_m, udp_dport, 0xFFFF);
-		MLX5_SET(fte_match_set_lyr_2_4, headers_v, udp_dport, dport);
+		MLX5_SET(fte_match_set_lyr_2_4, headers_v, udp_dport,
+			 MLX5_UDP_PORT_VXLAN_GPE);
+	}
+	if (!vxlan_v) {
+		vxlan_v = &dummy_vxlan_gpe_hdr;
+		vxlan_m = &dummy_vxlan_gpe_hdr;
+	} else {
+		if (!vxlan_m)
+			vxlan_m = &rte_flow_item_vxlan_gpe_mask;
 	}
-	if (!vxlan_v)
-		return;
-	if (!vxlan_m)
-		vxlan_m = &rte_flow_item_vxlan_gpe_mask;
-	size = sizeof(vxlan_m->vni);
-	vni_m = MLX5_ADDR_OF(fte_match_set_misc3, misc_m, outer_vxlan_gpe_vni);
-	vni_v = MLX5_ADDR_OF(fte_match_set_misc3, misc_v, outer_vxlan_gpe_vni);
 	memcpy(vni_m, vxlan_m->vni, size);
 	for (i = 0; i < size; ++i)
 		vni_v[i] = vni_m[i] & vxlan_v->vni[i];
@@ -9011,10 +9005,22 @@ flow_dv_translate_item_vxlan_gpe(void *matcher, void *key,
 	}
 	MLX5_SET(fte_match_set_misc3, misc_m, outer_vxlan_gpe_flags, flags_m);
 	MLX5_SET(fte_match_set_misc3, misc_v, outer_vxlan_gpe_flags, flags_v);
-	MLX5_SET(fte_match_set_misc3, misc_m, outer_vxlan_gpe_next_protocol,
-		 vxlan_m->protocol);
-	MLX5_SET(fte_match_set_misc3, misc_v, outer_vxlan_gpe_next_protocol,
-		 vxlan_v->protocol);
+	m_protocol = vxlan_m->protocol;
+	v_protocol = vxlan_v->protocol;
+	if (!m_protocol) {
+		m_protocol = 0xff;
+		/* Force next protocol to ensure next headers parsing. */
+		if (pattern_flags & MLX5_FLOW_LAYER_INNER_L2)
+			v_protocol = RTE_VXLAN_GPE_TYPE_ETH;
+		else if (pattern_flags & MLX5_FLOW_LAYER_INNER_L3_IPV4)
+			v_protocol = RTE_VXLAN_GPE_TYPE_IPV4;
+		else if (pattern_flags & MLX5_FLOW_LAYER_INNER_L3_IPV6)
+			v_protocol = RTE_VXLAN_GPE_TYPE_IPV6;
+	}
+	MLX5_SET(fte_match_set_misc3, misc_m,
+		 outer_vxlan_gpe_next_protocol, m_protocol);
+	MLX5_SET(fte_match_set_misc3, misc_v,
+		 outer_vxlan_gpe_next_protocol, m_protocol & v_protocol);
 }
 
 /**
@@ -12644,6 +12650,7 @@ flow_dv_translate(struct rte_eth_dev *dev,
 		.std_tbl_fix = true,
 	};
 	const struct rte_flow_item *integrity_items[2] = {NULL, NULL};
+	const struct rte_flow_item *tunnel_item = NULL;
 
 	if (!wks)
 		return rte_flow_error_set(error, ENOMEM,
@@ -13437,11 +13444,9 @@ flow_dv_translate(struct rte_eth_dev *dev,
 			last_item = MLX5_FLOW_LAYER_VXLAN;
 			break;
 		case RTE_FLOW_ITEM_TYPE_VXLAN_GPE:
-			flow_dv_translate_item_vxlan_gpe(match_mask,
-							 match_value, items,
-							 tunnel);
 			matcher.priority = MLX5_TUNNEL_PRIO_GET(rss_desc);
 			last_item = MLX5_FLOW_LAYER_VXLAN_GPE;
+			tunnel_item = items;
 			break;
 		case RTE_FLOW_ITEM_TYPE_GENEVE:
 			flow_dv_translate_item_geneve(match_mask, match_value,
@@ -13573,6 +13578,9 @@ flow_dv_translate(struct rte_eth_dev *dev,
 						      integrity_items,
 						      item_flags);
 	}
+	if (item_flags & MLX5_FLOW_LAYER_VXLAN_GPE)
+		flow_dv_translate_item_vxlan_gpe(match_mask, match_value,
+						 tunnel_item, item_flags);
 #ifdef RTE_LIBRTE_MLX5_DEBUG
 	MLX5_ASSERT(!flow_dv_check_valid_spec(matcher.mask.buf,
 					      dev_flow->dv.value.buf));
-- 
2.33.1


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH 2/5] net/mlx5: add Ethernet header to GENEVE RSS expansion
  2021-11-14 15:36 [PATCH 1/5] net/mlx5: fix VXLAN-GPE next protocol translation Gregory Etelson
@ 2021-11-14 15:36 ` Gregory Etelson
  2021-11-15  7:47   ` Slava Ovsiienko
  2021-11-14 15:36 ` [PATCH 3/5] net/mlx5: fix RSS expansion scheme for GRE header Gregory Etelson
                   ` (4 subsequent siblings)
  5 siblings, 1 reply; 11+ messages in thread
From: Gregory Etelson @ 2021-11-14 15:36 UTC (permalink / raw)
  To: dev, getelson; +Cc: matan, rasland, stable, Viacheslav Ovsiienko

RFC-8926 allows inner Ethernet header after GENEVE
tunnel.

Current GENEVE RSS expansion created IPv4 and IPv6 paths
only.

The patch adds Ethernet to RSS expansion scheme.

Cc: stable@dpdk.org
Signed-off-by: Gregory Etelson <getelson@nvidia.com>
---
 drivers/net/mlx5/mlx5_flow.c | 34 +++++++++++++++++++++++++++++++++-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index f657980737..205fe19cdd 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -258,6 +258,29 @@ mlx5_flow_expand_rss_item_complete(const struct rte_flow_item *item)
 		else
 			ret = RTE_FLOW_ITEM_TYPE_END;
 		break;
+	case RTE_FLOW_ITEM_TYPE_GENEVE:
+		ether_type_m = item->mask ?
+			       ((const struct rte_flow_item_geneve *)
+			       (item->mask))->protocol :
+			       rte_flow_item_geneve_mask.protocol;
+		ether_type = ((const struct rte_flow_item_geneve *)
+			     (item->spec))->protocol;
+		ether_type_m = rte_be_to_cpu_16(ether_type_m);
+		ether_type = rte_be_to_cpu_16(ether_type);
+		switch (ether_type_m & ether_type) {
+		case RTE_ETHER_TYPE_TEB:
+			ret = RTE_FLOW_ITEM_TYPE_ETH;
+			break;
+		case RTE_ETHER_TYPE_IPV4:
+			ret = RTE_FLOW_ITEM_TYPE_IPV4;
+			break;
+		case RTE_ETHER_TYPE_IPV6:
+			ret = RTE_FLOW_ITEM_TYPE_IPV6;
+			break;
+		default:
+			ret = RTE_FLOW_ITEM_TYPE_END;
+		}
+		break;
 	default:
 		ret = RTE_FLOW_ITEM_TYPE_VOID;
 		break;
@@ -530,7 +553,8 @@ enum mlx5_expansion {
 	MLX5_EXPANSION_IPV6_UDP,
 	MLX5_EXPANSION_IPV6_TCP,
 	MLX5_EXPANSION_IPV6_FRAG_EXT,
-	MLX5_EXPANSION_GTP
+	MLX5_EXPANSION_GTP,
+	MLX5_EXPANSION_GENEVE,
 };
 
 /** Supported expansion of items. */
@@ -574,6 +598,7 @@ static const struct mlx5_flow_expand_node mlx5_support_expansion[] = {
 		.next = MLX5_FLOW_EXPAND_RSS_NEXT(MLX5_EXPANSION_VXLAN,
 						  MLX5_EXPANSION_VXLAN_GPE,
 						  MLX5_EXPANSION_MPLS,
+						  MLX5_EXPANSION_GENEVE,
 						  MLX5_EXPANSION_GTP),
 		.type = RTE_FLOW_ITEM_TYPE_UDP,
 		.rss_types = RTE_ETH_RSS_NONFRAG_IPV4_UDP,
@@ -598,6 +623,7 @@ static const struct mlx5_flow_expand_node mlx5_support_expansion[] = {
 		.next = MLX5_FLOW_EXPAND_RSS_NEXT(MLX5_EXPANSION_VXLAN,
 						  MLX5_EXPANSION_VXLAN_GPE,
 						  MLX5_EXPANSION_MPLS,
+						  MLX5_EXPANSION_GENEVE,
 						  MLX5_EXPANSION_GTP),
 		.type = RTE_FLOW_ITEM_TYPE_UDP,
 		.rss_types = RTE_ETH_RSS_NONFRAG_IPV6_UDP,
@@ -701,6 +727,12 @@ static const struct mlx5_flow_expand_node mlx5_support_expansion[] = {
 						  MLX5_EXPANSION_IPV6),
 		.type = RTE_FLOW_ITEM_TYPE_GTP,
 	},
+	[MLX5_EXPANSION_GENEVE] = {
+		.next = MLX5_FLOW_EXPAND_RSS_NEXT(MLX5_EXPANSION_ETH,
+						  MLX5_EXPANSION_IPV4,
+						  MLX5_EXPANSION_IPV6),
+		.type = RTE_FLOW_ITEM_TYPE_GENEVE,
+	},
 };
 
 static struct rte_flow_action_handle *
-- 
2.33.1


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH 3/5] net/mlx5: fix RSS expansion scheme for GRE header
  2021-11-14 15:36 [PATCH 1/5] net/mlx5: fix VXLAN-GPE next protocol translation Gregory Etelson
  2021-11-14 15:36 ` [PATCH 2/5] net/mlx5: add Ethernet header to GENEVE RSS expansion Gregory Etelson
@ 2021-11-14 15:36 ` Gregory Etelson
  2021-11-15  7:52   ` Slava Ovsiienko
  2021-11-14 15:36 ` [PATCH 4/5] net/mlx5: fix GENEVE protocol type translation Gregory Etelson
                   ` (3 subsequent siblings)
  5 siblings, 1 reply; 11+ messages in thread
From: Gregory Etelson @ 2021-11-14 15:36 UTC (permalink / raw)
  To: dev, getelson
  Cc: matan, rasland, stable, Viacheslav Ovsiienko, Yongseok Koh,
	Nelio Laranjeiro

RFC-2784 allows any valid Ethernet type in GRE protocol type field.

Add Ethernet to GRE RSS expansion.

Cc: stable@dpdk.org

Fixes: f4b901a46aec ("net/mlx5: add flow GRE item")
Signed-off-by: Gregory Etelson <getelson@nvidia.com>
---
 drivers/net/mlx5/mlx5_flow.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 205fe19cdd..43598f92ee 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -654,7 +654,8 @@ static const struct mlx5_flow_expand_node mlx5_support_expansion[] = {
 		.type = RTE_FLOW_ITEM_TYPE_VXLAN_GPE,
 	},
 	[MLX5_EXPANSION_GRE] = {
-		.next = MLX5_FLOW_EXPAND_RSS_NEXT(MLX5_EXPANSION_IPV4,
+		.next = MLX5_FLOW_EXPAND_RSS_NEXT(MLX5_EXPANSION_ETH,
+						  MLX5_EXPANSION_IPV4,
 						  MLX5_EXPANSION_IPV6,
 						  MLX5_EXPANSION_GRE_KEY,
 						  MLX5_EXPANSION_MPLS),
-- 
2.33.1


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH 4/5] net/mlx5: fix GENEVE protocol type translation
  2021-11-14 15:36 [PATCH 1/5] net/mlx5: fix VXLAN-GPE next protocol translation Gregory Etelson
  2021-11-14 15:36 ` [PATCH 2/5] net/mlx5: add Ethernet header to GENEVE RSS expansion Gregory Etelson
  2021-11-14 15:36 ` [PATCH 3/5] net/mlx5: fix RSS expansion scheme for GRE header Gregory Etelson
@ 2021-11-14 15:36 ` Gregory Etelson
  2021-11-15  7:54   ` Slava Ovsiienko
  2021-11-14 15:36 ` [PATCH 5/5] net/mlx5: fix GRE " Gregory Etelson
                   ` (2 subsequent siblings)
  5 siblings, 1 reply; 11+ messages in thread
From: Gregory Etelson @ 2021-11-14 15:36 UTC (permalink / raw)
  To: dev, getelson
  Cc: matan, rasland, stable, Viacheslav Ovsiienko, Moti Haimovsky

When application creates several flows to match on GENEVE tunnel
without explicitly specifying GENEVE protocol type value in
flow rules, PMD will translate that to zero mask.
RDMA-CORE cannot distinguish between different inner flow types and
produces identical matchers for each zero mask.

The patch extracts inner header type from flow rule and forces it
in GENEVE protocol type, if application did not specify
any without explicitly specifying GENEVE protocol type value in
flow rules, protocol type value.

Cc: stable@dpdk.org

Fixes: e59a5dbcfd07 ("net/mlx5: add flow match on GENEVE item")
Signed-off-by: Gregory Etelson <getelson@nvidia.com>
---
 drivers/net/mlx5/mlx5_flow_dv.c | 78 ++++++++++++++++++++-------------
 1 file changed, 47 insertions(+), 31 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index f9acb69cca..bce504391d 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -93,6 +93,20 @@ static int
 flow_dv_jump_tbl_resource_release(struct rte_eth_dev *dev,
 				  uint32_t rix_jump);
 
+static inline uint16_t
+mlx5_translate_tunnel_etypes(uint64_t pattern_flags)
+{
+	if (pattern_flags & MLX5_FLOW_LAYER_INNER_L2)
+		return RTE_ETHER_TYPE_TEB;
+	else if (pattern_flags & MLX5_FLOW_LAYER_INNER_L3_IPV4)
+		return RTE_ETHER_TYPE_IPV4;
+	else if (pattern_flags & MLX5_FLOW_LAYER_INNER_L3_IPV6)
+		return RTE_ETHER_TYPE_IPV6;
+	else if (pattern_flags & MLX5_FLOW_LAYER_MPLS)
+		return RTE_ETHER_TYPE_MPLS;
+	return 0;
+}
+
 static int16_t
 flow_dv_get_esw_manager_vport_id(struct rte_eth_dev *dev)
 {
@@ -9038,49 +9052,39 @@ flow_dv_translate_item_vxlan_gpe(void *matcher, void *key,
 
 static void
 flow_dv_translate_item_geneve(void *matcher, void *key,
-			      const struct rte_flow_item *item, int inner)
+			      const struct rte_flow_item *item,
+			      uint64_t pattern_flags)
 {
+	static const struct rte_flow_item_geneve empty_geneve = {0,};
 	const struct rte_flow_item_geneve *geneve_m = item->mask;
 	const struct rte_flow_item_geneve *geneve_v = item->spec;
-	void *headers_m;
-	void *headers_v;
+	/* GENEVE flow item validation allows single tunnel item */
+	void *headers_m = MLX5_ADDR_OF(fte_match_param, matcher, outer_headers);
+	void *headers_v = MLX5_ADDR_OF(fte_match_param, key, outer_headers);
 	void *misc_m = MLX5_ADDR_OF(fte_match_param, matcher, misc_parameters);
 	void *misc_v = MLX5_ADDR_OF(fte_match_param, key, misc_parameters);
-	uint16_t dport;
 	uint16_t gbhdr_m;
 	uint16_t gbhdr_v;
-	char *vni_m;
-	char *vni_v;
-	size_t size, i;
+	char *vni_m = MLX5_ADDR_OF(fte_match_set_misc, misc_m, geneve_vni);
+	char *vni_v = MLX5_ADDR_OF(fte_match_set_misc, misc_v, geneve_vni);
+	size_t size = sizeof(geneve_m->vni), i;
+	uint16_t protocol_m, protocol_v;
 
-	if (inner) {
-		headers_m = MLX5_ADDR_OF(fte_match_param, matcher,
-					 inner_headers);
-		headers_v = MLX5_ADDR_OF(fte_match_param, key, inner_headers);
-	} else {
-		headers_m = MLX5_ADDR_OF(fte_match_param, matcher,
-					 outer_headers);
-		headers_v = MLX5_ADDR_OF(fte_match_param, key, outer_headers);
-	}
-	dport = MLX5_UDP_PORT_GENEVE;
 	if (!MLX5_GET16(fte_match_set_lyr_2_4, headers_v, udp_dport)) {
 		MLX5_SET(fte_match_set_lyr_2_4, headers_m, udp_dport, 0xFFFF);
-		MLX5_SET(fte_match_set_lyr_2_4, headers_v, udp_dport, dport);
+		MLX5_SET(fte_match_set_lyr_2_4, headers_v, udp_dport,
+			 MLX5_UDP_PORT_GENEVE);
+	}
+	if (!geneve_v) {
+		geneve_v = &empty_geneve;
+		geneve_m = &empty_geneve;
+	} else {
+		if (!geneve_m)
+			geneve_m = &rte_flow_item_geneve_mask;
 	}
-	if (!geneve_v)
-		return;
-	if (!geneve_m)
-		geneve_m = &rte_flow_item_geneve_mask;
-	size = sizeof(geneve_m->vni);
-	vni_m = MLX5_ADDR_OF(fte_match_set_misc, misc_m, geneve_vni);
-	vni_v = MLX5_ADDR_OF(fte_match_set_misc, misc_v, geneve_vni);
 	memcpy(vni_m, geneve_m->vni, size);
 	for (i = 0; i < size; ++i)
 		vni_v[i] = vni_m[i] & geneve_v->vni[i];
-	MLX5_SET(fte_match_set_misc, misc_m, geneve_protocol_type,
-		 rte_be_to_cpu_16(geneve_m->protocol));
-	MLX5_SET(fte_match_set_misc, misc_v, geneve_protocol_type,
-		 rte_be_to_cpu_16(geneve_v->protocol & geneve_m->protocol));
 	gbhdr_m = rte_be_to_cpu_16(geneve_m->ver_opt_len_o_c_rsvd0);
 	gbhdr_v = rte_be_to_cpu_16(geneve_v->ver_opt_len_o_c_rsvd0);
 	MLX5_SET(fte_match_set_misc, misc_m, geneve_oam,
@@ -9092,6 +9096,16 @@ flow_dv_translate_item_geneve(void *matcher, void *key,
 	MLX5_SET(fte_match_set_misc, misc_v, geneve_opt_len,
 		 MLX5_GENEVE_OPTLEN_VAL(gbhdr_v) &
 		 MLX5_GENEVE_OPTLEN_VAL(gbhdr_m));
+	protocol_m = rte_be_to_cpu_16(geneve_m->protocol);
+	protocol_v = rte_be_to_cpu_16(geneve_v->protocol);
+	if (!protocol_m) {
+		/* Force next protocol to prevent matchers duplication */
+		protocol_m = 0xFFFF;
+		protocol_v = mlx5_translate_tunnel_etypes(pattern_flags);
+	}
+	MLX5_SET(fte_match_set_misc, misc_m, geneve_protocol_type, protocol_m);
+	MLX5_SET(fte_match_set_misc, misc_v, geneve_protocol_type,
+		 protocol_m & protocol_v);
 }
 
 /**
@@ -13449,10 +13463,9 @@ flow_dv_translate(struct rte_eth_dev *dev,
 			tunnel_item = items;
 			break;
 		case RTE_FLOW_ITEM_TYPE_GENEVE:
-			flow_dv_translate_item_geneve(match_mask, match_value,
-						      items, tunnel);
 			matcher.priority = MLX5_TUNNEL_PRIO_GET(rss_desc);
 			last_item = MLX5_FLOW_LAYER_GENEVE;
+			tunnel_item = items;
 			break;
 		case RTE_FLOW_ITEM_TYPE_GENEVE_OPT:
 			ret = flow_dv_translate_item_geneve_opt(dev, match_mask,
@@ -13581,6 +13594,9 @@ flow_dv_translate(struct rte_eth_dev *dev,
 	if (item_flags & MLX5_FLOW_LAYER_VXLAN_GPE)
 		flow_dv_translate_item_vxlan_gpe(match_mask, match_value,
 						 tunnel_item, item_flags);
+	else if (item_flags & MLX5_FLOW_LAYER_GENEVE)
+		flow_dv_translate_item_geneve(match_mask, match_value,
+					      tunnel_item, item_flags);
 #ifdef RTE_LIBRTE_MLX5_DEBUG
 	MLX5_ASSERT(!flow_dv_check_valid_spec(matcher.mask.buf,
 					      dev_flow->dv.value.buf));
-- 
2.33.1


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH 5/5] net/mlx5: fix GRE protocol type translation
  2021-11-14 15:36 [PATCH 1/5] net/mlx5: fix VXLAN-GPE next protocol translation Gregory Etelson
                   ` (2 preceding siblings ...)
  2021-11-14 15:36 ` [PATCH 4/5] net/mlx5: fix GENEVE protocol type translation Gregory Etelson
@ 2021-11-14 15:36 ` Gregory Etelson
  2021-11-15  7:53   ` Slava Ovsiienko
  2021-11-15  7:46 ` [PATCH 1/5] net/mlx5: fix VXLAN-GPE next protocol translation Slava Ovsiienko
  2021-11-16  7:05 ` Raslan Darawsheh
  5 siblings, 1 reply; 11+ messages in thread
From: Gregory Etelson @ 2021-11-14 15:36 UTC (permalink / raw)
  To: dev, getelson
  Cc: matan, rasland, stable, Viacheslav Ovsiienko, Yongseok Koh, Ori Kam

When application creates several flows to match on GRE tunnel
without explicitly specifying GRE protocol type value in
flow rules, PMD will translate that to zero mask.
RDMA-CORE cannot distinguish between different inner flow types and
produces identical matchers for each zero mask.

The patch extracts inner header type from flow rule and forces it
in GRE protocol type, if application did not specify
any without explicitly specifying GRE protocol type value in
flow rules, protocol type value.

Cc: stable@dpdk.org

Fixes: fc2c498ccb94 ("net/mlx5: add Direct Verbs translate items")

Signed-off-by: Gregory Etelson <getelson@nvidia.com>
---
 drivers/net/mlx5/mlx5_flow_dv.c | 70 +++++++++++++++++++--------------
 1 file changed, 40 insertions(+), 30 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index bce504391d..287a17d956 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -8730,18 +8730,19 @@ flow_dv_translate_item_gre_key(void *matcher, void *key,
  *   Flow matcher value.
  * @param[in] item
  *   Flow pattern to translate.
- * @param[in] inner
- *   Item is inner pattern.
+ * @param[in] pattern_flags
+ *   Accumulated pattern flags.
  */
 static void
 flow_dv_translate_item_gre(void *matcher, void *key,
 			   const struct rte_flow_item *item,
-			   int inner)
+			   uint64_t pattern_flags)
 {
+	static const struct rte_flow_item_gre empty_gre = {0,};
 	const struct rte_flow_item_gre *gre_m = item->mask;
 	const struct rte_flow_item_gre *gre_v = item->spec;
-	void *headers_m;
-	void *headers_v;
+	void *headers_m = MLX5_ADDR_OF(fte_match_param, matcher, outer_headers);
+	void *headers_v = MLX5_ADDR_OF(fte_match_param, key, outer_headers);
 	void *misc_m = MLX5_ADDR_OF(fte_match_param, matcher, misc_parameters);
 	void *misc_v = MLX5_ADDR_OF(fte_match_param, key, misc_parameters);
 	struct {
@@ -8758,26 +8759,17 @@ flow_dv_translate_item_gre(void *matcher, void *key,
 			uint16_t value;
 		};
 	} gre_crks_rsvd0_ver_m, gre_crks_rsvd0_ver_v;
+	uint16_t protocol_m, protocol_v;
 
-	if (inner) {
-		headers_m = MLX5_ADDR_OF(fte_match_param, matcher,
-					 inner_headers);
-		headers_v = MLX5_ADDR_OF(fte_match_param, key, inner_headers);
-	} else {
-		headers_m = MLX5_ADDR_OF(fte_match_param, matcher,
-					 outer_headers);
-		headers_v = MLX5_ADDR_OF(fte_match_param, key, outer_headers);
-	}
 	MLX5_SET(fte_match_set_lyr_2_4, headers_m, ip_protocol, 0xff);
 	MLX5_SET(fte_match_set_lyr_2_4, headers_v, ip_protocol, IPPROTO_GRE);
-	if (!gre_v)
-		return;
-	if (!gre_m)
-		gre_m = &rte_flow_item_gre_mask;
-	MLX5_SET(fte_match_set_misc, misc_m, gre_protocol,
-		 rte_be_to_cpu_16(gre_m->protocol));
-	MLX5_SET(fte_match_set_misc, misc_v, gre_protocol,
-		 rte_be_to_cpu_16(gre_v->protocol & gre_m->protocol));
+	if (!gre_v) {
+		gre_v = &empty_gre;
+		gre_m = &empty_gre;
+	} else {
+		if (!gre_m)
+			gre_m = &rte_flow_item_gre_mask;
+	}
 	gre_crks_rsvd0_ver_m.value = rte_be_to_cpu_16(gre_m->c_rsvd0_ver);
 	gre_crks_rsvd0_ver_v.value = rte_be_to_cpu_16(gre_v->c_rsvd0_ver);
 	MLX5_SET(fte_match_set_misc, misc_m, gre_c_present,
@@ -8795,6 +8787,16 @@ flow_dv_translate_item_gre(void *matcher, void *key,
 	MLX5_SET(fte_match_set_misc, misc_v, gre_s_present,
 		 gre_crks_rsvd0_ver_v.s_present &
 		 gre_crks_rsvd0_ver_m.s_present);
+	protocol_m = rte_be_to_cpu_16(gre_m->protocol);
+	protocol_v = rte_be_to_cpu_16(gre_v->protocol);
+	if (!protocol_m) {
+		/* Force next protocol to prevent matchers duplication */
+		protocol_m = 0xFFFF;
+		protocol_v = mlx5_translate_tunnel_etypes(pattern_flags);
+	}
+	MLX5_SET(fte_match_set_misc, misc_m, gre_protocol, protocol_m);
+	MLX5_SET(fte_match_set_misc, misc_v, gre_protocol,
+		 protocol_m & protocol_v);
 }
 
 /**
@@ -8806,13 +8808,13 @@ flow_dv_translate_item_gre(void *matcher, void *key,
  *   Flow matcher value.
  * @param[in] item
  *   Flow pattern to translate.
- * @param[in] inner
- *   Item is inner pattern.
+ * @param[in] pattern_flags
+ *   Accumulated pattern flags.
  */
 static void
 flow_dv_translate_item_nvgre(void *matcher, void *key,
 			     const struct rte_flow_item *item,
-			     int inner)
+			     unsigned long pattern_flags)
 {
 	const struct rte_flow_item_nvgre *nvgre_m = item->mask;
 	const struct rte_flow_item_nvgre *nvgre_v = item->spec;
@@ -8839,7 +8841,7 @@ flow_dv_translate_item_nvgre(void *matcher, void *key,
 		.mask = &gre_mask,
 		.last = NULL,
 	};
-	flow_dv_translate_item_gre(matcher, key, &gre_item, inner);
+	flow_dv_translate_item_gre(matcher, key, &gre_item, pattern_flags);
 	if (!nvgre_v)
 		return;
 	if (!nvgre_m)
@@ -13434,10 +13436,9 @@ flow_dv_translate(struct rte_eth_dev *dev,
 					     MLX5_FLOW_LAYER_OUTER_L4_UDP;
 			break;
 		case RTE_FLOW_ITEM_TYPE_GRE:
-			flow_dv_translate_item_gre(match_mask, match_value,
-						   items, tunnel);
 			matcher.priority = MLX5_TUNNEL_PRIO_GET(rss_desc);
 			last_item = MLX5_FLOW_LAYER_GRE;
+			tunnel_item = items;
 			break;
 		case RTE_FLOW_ITEM_TYPE_GRE_KEY:
 			flow_dv_translate_item_gre_key(match_mask,
@@ -13445,10 +13446,9 @@ flow_dv_translate(struct rte_eth_dev *dev,
 			last_item = MLX5_FLOW_LAYER_GRE_KEY;
 			break;
 		case RTE_FLOW_ITEM_TYPE_NVGRE:
-			flow_dv_translate_item_nvgre(match_mask, match_value,
-						     items, tunnel);
 			matcher.priority = MLX5_TUNNEL_PRIO_GET(rss_desc);
 			last_item = MLX5_FLOW_LAYER_GRE;
+			tunnel_item = items;
 			break;
 		case RTE_FLOW_ITEM_TYPE_VXLAN:
 			flow_dv_translate_item_vxlan(dev, attr,
@@ -13597,6 +13597,16 @@ flow_dv_translate(struct rte_eth_dev *dev,
 	else if (item_flags & MLX5_FLOW_LAYER_GENEVE)
 		flow_dv_translate_item_geneve(match_mask, match_value,
 					      tunnel_item, item_flags);
+	else if (item_flags & MLX5_FLOW_LAYER_GRE) {
+		if (tunnel_item->type == RTE_FLOW_ITEM_TYPE_GRE)
+			flow_dv_translate_item_gre(match_mask, match_value,
+						   tunnel_item, item_flags);
+		else if (tunnel_item->type == RTE_FLOW_ITEM_TYPE_NVGRE)
+			flow_dv_translate_item_nvgre(match_mask, match_value,
+						     tunnel_item, item_flags);
+		else
+			MLX5_ASSERT(false);
+	}
 #ifdef RTE_LIBRTE_MLX5_DEBUG
 	MLX5_ASSERT(!flow_dv_check_valid_spec(matcher.mask.buf,
 					      dev_flow->dv.value.buf));
-- 
2.33.1


^ permalink raw reply	[flat|nested] 11+ messages in thread

* RE: [PATCH 1/5] net/mlx5: fix VXLAN-GPE next protocol translation
  2021-11-14 15:36 [PATCH 1/5] net/mlx5: fix VXLAN-GPE next protocol translation Gregory Etelson
                   ` (3 preceding siblings ...)
  2021-11-14 15:36 ` [PATCH 5/5] net/mlx5: fix GRE " Gregory Etelson
@ 2021-11-15  7:46 ` Slava Ovsiienko
  2021-11-16  7:05 ` Raslan Darawsheh
  5 siblings, 0 replies; 11+ messages in thread
From: Slava Ovsiienko @ 2021-11-15  7:46 UTC (permalink / raw)
  To: Gregory Etelson, dev
  Cc: Matan Azrad, Raslan Darawsheh, stable, Raslan Darawsheh

> -----Original Message-----
> From: Gregory Etelson <getelson@nvidia.com>
> Sent: Sunday, November 14, 2021 17:36
> To: dev@dpdk.org; Gregory Etelson <getelson@nvidia.com>
> Cc: Matan Azrad <matan@nvidia.com>; Raslan Darawsheh
> <rasland@nvidia.com>; stable@dpdk.org; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Raslan Darawsheh <rasland@nvidia.com>
> Subject: [PATCH 1/5] net/mlx5: fix VXLAN-GPE next protocol translation
> 
> VXLAN-GPE extends VXLAN protocol and provides the next protocol field
> specifying the first inner header type.
> 
> The application can assign some explicit value to VXLAN-GPE::next_protocol
> field or set it to the default one. In the latter case, the rdma-core library
> cannot recognize the matcher built by PMD correctly, and it results in
> hardware configuration missing inner headers match.
> 
> The patch forces VXLAN-GPE::next_protocol assignment if the application did
> not explicitly assign it to the non-default value
> 
> Cc: stable@dpdk.org
> 
> Fixes: 90456726eb80 ("net/mlx5: fix VXLAN-GPE item translation")
> Signed-off-by: Gregory Etelson <getelson@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>

^ permalink raw reply	[flat|nested] 11+ messages in thread

* RE: [PATCH 2/5] net/mlx5: add Ethernet header to GENEVE RSS expansion
  2021-11-14 15:36 ` [PATCH 2/5] net/mlx5: add Ethernet header to GENEVE RSS expansion Gregory Etelson
@ 2021-11-15  7:47   ` Slava Ovsiienko
  0 siblings, 0 replies; 11+ messages in thread
From: Slava Ovsiienko @ 2021-11-15  7:47 UTC (permalink / raw)
  To: Gregory Etelson, dev; +Cc: Matan Azrad, Raslan Darawsheh, stable

> -----Original Message-----
> From: Gregory Etelson <getelson@nvidia.com>
> Sent: Sunday, November 14, 2021 17:36
> To: dev@dpdk.org; Gregory Etelson <getelson@nvidia.com>
> Cc: Matan Azrad <matan@nvidia.com>; Raslan Darawsheh
> <rasland@nvidia.com>; stable@dpdk.org; Slava Ovsiienko
> <viacheslavo@nvidia.com>
> Subject: [PATCH 2/5] net/mlx5: add Ethernet header to GENEVE RSS
> expansion
> 
> RFC-8926 allows inner Ethernet header after GENEVE tunnel.
> 
> Current GENEVE RSS expansion created IPv4 and IPv6 paths only.
> 
> The patch adds Ethernet to RSS expansion scheme.
> 
> Cc: stable@dpdk.org
> Signed-off-by: Gregory Etelson <getelson@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>


^ permalink raw reply	[flat|nested] 11+ messages in thread

* RE: [PATCH 3/5] net/mlx5: fix RSS expansion scheme for GRE header
  2021-11-14 15:36 ` [PATCH 3/5] net/mlx5: fix RSS expansion scheme for GRE header Gregory Etelson
@ 2021-11-15  7:52   ` Slava Ovsiienko
  0 siblings, 0 replies; 11+ messages in thread
From: Slava Ovsiienko @ 2021-11-15  7:52 UTC (permalink / raw)
  To: Gregory Etelson, dev
  Cc: Matan Azrad, Raslan Darawsheh, stable, Yongseok Koh,
	NBU-Contact-N?lio Laranjeiro

> -----Original Message-----
> From: Gregory Etelson <getelson@nvidia.com>
> Sent: Sunday, November 14, 2021 17:36
> To: dev@dpdk.org; Gregory Etelson <getelson@nvidia.com>
> Cc: Matan Azrad <matan@nvidia.com>; Raslan Darawsheh
> <rasland@nvidia.com>; stable@dpdk.org; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Yongseok Koh <yskoh@mellanox.com>; NBU-
> Contact-N?lio Laranjeiro <nelio.laranjeiro@6wind.com>
> Subject: [PATCH 3/5] net/mlx5: fix RSS expansion scheme for GRE header
> 
> RFC-2784 allows any valid Ethernet type in GRE protocol type field.
> 
> Add Ethernet to GRE RSS expansion.
> 
> Cc: stable@dpdk.org
> 
> Fixes: f4b901a46aec ("net/mlx5: add flow GRE item")
> Signed-off-by: Gregory Etelson <getelson@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>


^ permalink raw reply	[flat|nested] 11+ messages in thread

* RE: [PATCH 5/5] net/mlx5: fix GRE protocol type translation
  2021-11-14 15:36 ` [PATCH 5/5] net/mlx5: fix GRE " Gregory Etelson
@ 2021-11-15  7:53   ` Slava Ovsiienko
  0 siblings, 0 replies; 11+ messages in thread
From: Slava Ovsiienko @ 2021-11-15  7:53 UTC (permalink / raw)
  To: Gregory Etelson, dev
  Cc: Matan Azrad, Raslan Darawsheh, stable, Yongseok Koh, Ori Kam

> -----Original Message-----
> From: Gregory Etelson <getelson@nvidia.com>
> Sent: Sunday, November 14, 2021 17:36
> To: dev@dpdk.org; Gregory Etelson <getelson@nvidia.com>
> Cc: Matan Azrad <matan@nvidia.com>; Raslan Darawsheh
> <rasland@nvidia.com>; stable@dpdk.org; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Yongseok Koh <yskoh@mellanox.com>; Ori Kam
> <orika@nvidia.com>
> Subject: [PATCH 5/5] net/mlx5: fix GRE protocol type translation
> 
> When application creates several flows to match on GRE tunnel without
> explicitly specifying GRE protocol type value in flow rules, PMD will translate
> that to zero mask.
> RDMA-CORE cannot distinguish between different inner flow types and
> produces identical matchers for each zero mask.
> 
> The patch extracts inner header type from flow rule and forces it in GRE
> protocol type, if application did not specify any without explicitly specifying
> GRE protocol type value in flow rules, protocol type value.
> 
> Cc: stable@dpdk.org
> 
> Fixes: fc2c498ccb94 ("net/mlx5: add Direct Verbs translate items")
> 
> Signed-off-by: Gregory Etelson <getelson@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>


^ permalink raw reply	[flat|nested] 11+ messages in thread

* RE: [PATCH 4/5] net/mlx5: fix GENEVE protocol type translation
  2021-11-14 15:36 ` [PATCH 4/5] net/mlx5: fix GENEVE protocol type translation Gregory Etelson
@ 2021-11-15  7:54   ` Slava Ovsiienko
  0 siblings, 0 replies; 11+ messages in thread
From: Slava Ovsiienko @ 2021-11-15  7:54 UTC (permalink / raw)
  To: Gregory Etelson, dev; +Cc: Matan Azrad, Raslan Darawsheh, stable

> -----Original Message-----
> From: Gregory Etelson <getelson@nvidia.com>
> Sent: Sunday, November 14, 2021 17:36
> To: dev@dpdk.org; Gregory Etelson <getelson@nvidia.com>
> Cc: Matan Azrad <matan@nvidia.com>; Raslan Darawsheh
> <rasland@nvidia.com>; stable@dpdk.org; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Moti Haimovsky <motih@mellanox.com>
> Subject: [PATCH 4/5] net/mlx5: fix GENEVE protocol type translation
> 
> When application creates several flows to match on GENEVE tunnel without
> explicitly specifying GENEVE protocol type value in flow rules, PMD will
> translate that to zero mask.
> RDMA-CORE cannot distinguish between different inner flow types and
> produces identical matchers for each zero mask.
> 
> The patch extracts inner header type from flow rule and forces it in GENEVE
> protocol type, if application did not specify any without explicitly specifying
> GENEVE protocol type value in flow rules, protocol type value.
> 
> Cc: stable@dpdk.org
> 
> Fixes: e59a5dbcfd07 ("net/mlx5: add flow match on GENEVE item")
> Signed-off-by: Gregory Etelson <getelson@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>


^ permalink raw reply	[flat|nested] 11+ messages in thread

* RE: [PATCH 1/5] net/mlx5: fix VXLAN-GPE next protocol translation
  2021-11-14 15:36 [PATCH 1/5] net/mlx5: fix VXLAN-GPE next protocol translation Gregory Etelson
                   ` (4 preceding siblings ...)
  2021-11-15  7:46 ` [PATCH 1/5] net/mlx5: fix VXLAN-GPE next protocol translation Slava Ovsiienko
@ 2021-11-16  7:05 ` Raslan Darawsheh
  5 siblings, 0 replies; 11+ messages in thread
From: Raslan Darawsheh @ 2021-11-16  7:05 UTC (permalink / raw)
  To: Gregory Etelson, dev; +Cc: Matan Azrad, stable, Slava Ovsiienko

Hi,

> -----Original Message-----
> From: Gregory Etelson <getelson@nvidia.com>
> Sent: Sunday, November 14, 2021 5:36 PM
> To: dev@dpdk.org; Gregory Etelson <getelson@nvidia.com>
> Cc: Matan Azrad <matan@nvidia.com>; Raslan Darawsheh
> <rasland@nvidia.com>; stable@dpdk.org; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Raslan Darawsheh <rasland@nvidia.com>
> Subject: [PATCH 1/5] net/mlx5: fix VXLAN-GPE next protocol translation
> 
> VXLAN-GPE extends VXLAN protocol and provides the next protocol
> field specifying the first inner header type.
> 
> The application can assign some explicit value to
> VXLAN-GPE::next_protocol field or set it to the default one. In the
> latter case, the rdma-core library cannot recognize the matcher
> built by PMD correctly, and it results in hardware configuration
> missing inner headers match.
> 
> The patch forces VXLAN-GPE::next_protocol assignment if the
> application did not explicitly assign it to the non-default value
> 
> Cc: stable@dpdk.org
> 
> Fixes: 90456726eb80 ("net/mlx5: fix VXLAN-GPE item translation")
> Signed-off-by: Gregory Etelson <getelson@nvidia.com>

Series applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2021-11-16  7:05 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-14 15:36 [PATCH 1/5] net/mlx5: fix VXLAN-GPE next protocol translation Gregory Etelson
2021-11-14 15:36 ` [PATCH 2/5] net/mlx5: add Ethernet header to GENEVE RSS expansion Gregory Etelson
2021-11-15  7:47   ` Slava Ovsiienko
2021-11-14 15:36 ` [PATCH 3/5] net/mlx5: fix RSS expansion scheme for GRE header Gregory Etelson
2021-11-15  7:52   ` Slava Ovsiienko
2021-11-14 15:36 ` [PATCH 4/5] net/mlx5: fix GENEVE protocol type translation Gregory Etelson
2021-11-15  7:54   ` Slava Ovsiienko
2021-11-14 15:36 ` [PATCH 5/5] net/mlx5: fix GRE " Gregory Etelson
2021-11-15  7:53   ` Slava Ovsiienko
2021-11-15  7:46 ` [PATCH 1/5] net/mlx5: fix VXLAN-GPE next protocol translation Slava Ovsiienko
2021-11-16  7:05 ` Raslan Darawsheh

patches for DPDK stable branches

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.dpdk.org/stable/0 stable/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 stable stable/ http://inbox.dpdk.org/stable \
		stable@dpdk.org
	public-inbox-index stable

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.stable


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git