net/mlx5: fix tunnel offload private items location

Flow rules used in tunnel offload model require application to query PMD for private flow elements and explicitly add these elements to flow rule.

Tunnel offload model does not restrict private elements location in a flow rule.
The patch places tunnel offload private PMD flow elements between general RTE flow elements in a rule.

Fixes 1b9f274623b8 ("app/testpmd: add commands for tunnel offload")

Cc [email protected]

Signed-off-by Gregory Etelson <[email protected]>

Acked-by Viacheslav Ovsiienko <[email protected]>

---
  app/test-pmd/config.c | 14 ++++++++------
  1 file changed, 8 insertions(+), 6 deletions(-)

app/test-pmd/config.c +8 -6

index ef0b9784d..da5e843fd 100644
@@ -1663,7 +1663,7 @@ port_flow_tunnel_offload_cmd_prep(portid_t port_id,
  		     aptr->type != RTE_FLOW_ACTION_TYPE_END;
  		     aptr++, num_actions++);
  		pft->actions = malloc(
-				(num_actions +  pft->num_pmd_actions) *
+				(num_actions +  pft->num_pmd_actions + 1) *
  				sizeof(actions[0]));
  		if (!pft->actions) {
  			rte_flow_tunnel_action_decap_release(

@@ -1671,9 +1671,10 @@ port_flow_tunnel_offload_cmd_prep(portid_t port_id,
  					pft->num_pmd_actions, &error);
  			return NULL;
  		}
-		rte_memcpy(pft->actions, pft->pmd_actions,
+		pft->actions[0].type = RTE_FLOW_ACTION_TYPE_VOID;
+		rte_memcpy(pft->actions + 1, pft->pmd_actions,
  			   pft->num_pmd_actions * sizeof(actions[0]));
-		rte_memcpy(pft->actions + pft->num_pmd_actions, actions,
+		rte_memcpy(pft->actions + pft->num_pmd_actions + 1, actions,
  			   num_actions * sizeof(actions[0]));
  	}
  	if (tunnel_ops->items) {

@@ -1691,7 +1692,7 @@ port_flow_tunnel_offload_cmd_prep(portid_t port_id,
  		for (iptr = pattern, num_items = 1;
  		     iptr->type != RTE_FLOW_ITEM_TYPE_END;
  		     iptr++, num_items++);
-		pft->items = malloc((num_items + pft->num_pmd_items) *
+		pft->items = malloc((num_items + pft->num_pmd_items + 1) *
  				    sizeof(pattern[0]));
  		if (!pft->items) {
  			rte_flow_tunnel_item_release(

@@ -1699,9 +1700,10 @@ port_flow_tunnel_offload_cmd_prep(portid_t port_id,
  					pft->num_pmd_items, &error);
  			return NULL;
  		}
-		rte_memcpy(pft->items, pft->pmd_items,
+		pft->items[0].type = RTE_FLOW_ITEM_TYPE_VOID;
+		rte_memcpy(pft->items + 1, pft->pmd_items,
  			   pft->num_pmd_items * sizeof(pattern[0]));
-		rte_memcpy(pft->items + pft->num_pmd_items, pattern,
+		rte_memcpy(pft->items + pft->num_pmd_items + 1, pattern,
  			   num_items * sizeof(pattern[0]));
  	}
 

Tunnel offload API requires application to query PMD for specific flow items and actions. Application uses these PMD specific elements to build flow rules according to the tunnel offload model.

The model does not restrict private elements location in a flow rule, but the current MLX5 PMD implementation expected that tunnel offload rule will begin with PMD specific elements.

The patch places tunnel offload private PMD flow elements between general RTE flow elements in a rule.

Cc [email protected]

Fixes 1b9f274623b8 ("app/testpmd: add commands for tunnel offload")

Signed-off-by Gregory Etelson <[email protected]>

Acked-by Viacheslav Ovsiienko <[email protected]>

---
 app/test-pmd/config.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

app/test-pmd/config.c +8 -6

index 40b2b29725..1520b8193f 100644
@@ -1664,7 +1664,7 @@ port_flow_tunnel_offload_cmd_prep(portid_t port_id,
 		     aptr->type != RTE_FLOW_ACTION_TYPE_END;
 		     aptr++, num_actions++);
 		pft->actions = malloc(
-				(num_actions +  pft->num_pmd_actions) *
+				(num_actions +  pft->num_pmd_actions + 1) *
 				sizeof(actions[0]));
 		if (!pft->actions) {
 			rte_flow_tunnel_action_decap_release(

@@ -1672,9 +1672,10 @@ port_flow_tunnel_offload_cmd_prep(portid_t port_id,
 					pft->num_pmd_actions, &error);
 			return NULL;
 		}
-		rte_memcpy(pft->actions, pft->pmd_actions,
+		pft->actions[0].type = RTE_FLOW_ACTION_TYPE_VOID;
+		rte_memcpy(pft->actions + 1, pft->pmd_actions,
 			   pft->num_pmd_actions * sizeof(actions[0]));
-		rte_memcpy(pft->actions + pft->num_pmd_actions, actions,
+		rte_memcpy(pft->actions + pft->num_pmd_actions + 1, actions,
 			   num_actions * sizeof(actions[0]));
 	}
 	if (tunnel_ops->items) {

@@ -1692,7 +1693,7 @@ port_flow_tunnel_offload_cmd_prep(portid_t port_id,
 		for (iptr = pattern, num_items = 1;
 		     iptr->type != RTE_FLOW_ITEM_TYPE_END;
 		     iptr++, num_items++);
-		pft->items = malloc((num_items + pft->num_pmd_items) *
+		pft->items = malloc((num_items + pft->num_pmd_items + 1) *
 				    sizeof(pattern[0]));
 		if (!pft->items) {
 			rte_flow_tunnel_item_release(

@@ -1700,9 +1701,10 @@ port_flow_tunnel_offload_cmd_prep(portid_t port_id,
 					pft->num_pmd_items, &error);
 			return NULL;
 		}
-		rte_memcpy(pft->items, pft->pmd_items,
+		pft->items[0].type = RTE_FLOW_ITEM_TYPE_VOID;
+		rte_memcpy(pft->items + 1, pft->pmd_items,
 			   pft->num_pmd_items * sizeof(pattern[0]));
-		rte_memcpy(pft->items + pft->num_pmd_items, pattern,
+		rte_memcpy(pft->items + pft->num_pmd_items + 1, pattern,
 			   num_items * sizeof(pattern[0]));
 	}
 

Tunnel offload API requires application to query PMD for specific flow items and actions. Application uses these PMD specific elements to build flow rules according to the tunnel offload model.
The model does not restrict private elements location in a flow rule, but the current MLX5 PMD implementation expects that tunnel offload rule will begin with PMD specific elements.
The patch removes that placement limitation in MLX5 PMD.

Cc [email protected]

Fixes 4ec6360de37d ("net/mlx5: implement tunnel offload")

Dim 25 avr 2021, à 17:57, Gregory Etelson a écrit :

Quoted 8 lines

Tunnel offload API requires application to query PMD for specific flow items and actions. Application uses these PMD specific elements to build flow rules according to the tunnel offload model.
The model does not restrict private elements location in a flow rule, but the current MLX5 PMD implementation expects that tunnel offload rule will begin with PMD specific elements.
The patch removes that placement limitation in MLX5 PMD.

Quoted 3 lines

Cc [email protected]

Fixes 4ec6360de37d ("net/mlx5: implement tunnel offload")

Cc stable must be just after the Fixes line.

There is a testpmd patch in the same series, is it OK to be merged in mlx tree?

Hello Thomas,

Quoted 15 lines

Dim 25 avr 2021, à 17:57, Gregory Etelson a écrit :

Quoted 11 lines

Tunnel offload API requires application to query PMD for specific flow items and actions. Application uses these PMD specific elements to build flow rules according to the tunnel offload model.
The model does not restrict private elements location in a flow rule, but the current MLX5 PMD implementation expects that tunnel offload rule will begin with PMD specific elements.
The patch removes that placement limitation in MLX5 PMD.

Cc [email protected]

Fixes 4ec6360de37d ("net/mlx5: implement tunnel offload")

Cc stable must be just after the Fixes line.

Quoted 2 lines

There is a testpmd patch in the same series, is it OK to be merged in mlx tree?

The tunnel offload model can be complicated.
The testpmd patch that comes with this one emphasizes how application can construct a flow rule without placement restrictions. I think that both patches should be merged.

Dim 25 avr 2021, à 19:01, Gregory Etelson a écrit :

Quoted 17 lines

Hello Thomas,

Quoted 15 lines

Dim 25 avr 2021, à 17:57, Gregory Etelson a écrit :

Quoted 11 lines

Tunnel offload API requires application to query PMD for specific flow items and actions. Application uses these PMD specific elements to build flow rules according to the tunnel offload model.
The model does not restrict private elements location in a flow rule, but the current MLX5 PMD implementation expects that tunnel offload rule will begin with PMD specific elements.
The patch removes that placement limitation in MLX5 PMD.

Cc [email protected]

Fixes 4ec6360de37d ("net/mlx5: implement tunnel offload")

Cc stable must be just after the Fixes line.

Quoted 7 lines

Quoted 2 lines

There is a testpmd patch in the same series, is it OK to be merged in mlx tree?

The tunnel offload model can be complicated.
The testpmd patch that comes with this one emphasizes how application can construct a flow rule without placement restrictions. I think that both patches should be merged.

That's not the question.
One patch should be merged in mlx tree, while the other one should target next-net. In such a situation, quite often we split in different series.
For this case, it's up to Raslan and Ferruh to agree on how to proceed.

I am OK to get both to next-net, as long as driver patch is Ack'ed.

It seems there is a relation between driver and testpmd patch, but I am trying to figure out how tightly they are coupled, which may be sign of something wrong.

[snip]

Quoted 2 lines

I am OK to get both to next-net, as long as driver patch is Ack'ed.

[PATCH v2 1/2] net/mlx5: fix tunnel offload private items location was sent with Ack from Viacheslav Ovsiienko

Quoted 3 lines

It seems there is a relation between driver and testpmd patch, but I am trying to figure out how tightly they are coupled, which may be sign of something wrong.

The testpmd patch shows how application can construct flow rules for the tunnel offload model without items & actions locations restrictions.

Hello Ferruh,

Quoted 12 lines

[snip]

Quoted 2 lines

I am OK to get both to next-net, as long as driver patch is Ack'ed.

[PATCH v2 1/2] net/mlx5: fix tunnel offload private items location was sent with Ack from Viacheslav Ovsiienko

Quoted 3 lines

It seems there is a relation between driver and testpmd patch, but I am trying to figure out how tightly they are coupled, which may be sign of something wrong.

Quoted 2 lines

The testpmd patch shows how application can construct flow rules for the tunnel offload model without items & actions locations restrictions.

There was no progress with this patch.
Is it scheduled for 21.05 ?

I am OK to get both to next-net, as long as driver patch is Ack'ed.

It seems there is a relation between driver and testpmd patch, but I am trying to figure out how tightly they are coupled, which may be sign of something wrong.

-----Original Message-----
From: Gregory Etelson <[email protected]>
Sent: Sunday, May 2, 2021 11:08 AM
To: [email protected]
Cc: Gregory Etelson <[email protected]>; Matan Azrad <[email protected]>; Ori Kam <[email protected]>; Raslan Darawsheh <[email protected]>; [email protected]; Slava Ovsiienko <[email protected]>; Shahaf Shuler <[email protected]>
Subject: [PATCH v3] net/mlx5: fix tunnel offload private items location

Tunnel offload API requires application to query PMD for specific flow items and actions. Application uses these PMD specific elements to build flow rules according to the tunnel offload model.
The model does not restrict private elements location in a flow rule, but the current MLX5 PMD implementation expects that tunnel offload rule will begin with PMD specific elements.
The patch removes that placement limitation.

Cc [email protected]

Fixes 4ec6360de37d ("net/mlx5: implement tunnel offload")

Signed-off-by Gregory Etelson <[email protected]>

Acked-by Viacheslav Ovsiienko <[email protected]>

Tunnel offload API requires application to query PMD for specific flow items and actions. Application uses these PMD specific elements to build flow rules according to the tunnel offload model.
The model does not restrict private elements location in a flow rule, but the current MLX5 PMD implementation expects that tunnel offload rule will begin with PMD specific elements.
The patch removes that placement limitation.

Cc [email protected]

Fixes 4ec6360de37d ("net/mlx5: implement tunnel offload")

Signed-off-by Gregory Etelson <[email protected]>

Acked-by Viacheslav Ovsiienko <[email protected]>

Hi Gregory,

The were some questions around testpmd part of this patch in previous version, they are not answered and this version is dropping the testpmd part.

Is it safe to remove the testpmd part? If so why was the changes for at first place?

And can you please reply to the questions on the testpmd patch for the record?

Thanks,
Ferruh

Hello Ferruh,

[:snip:]

Quoted 6 lines

Hi Gregory,

The were some questions around testpmd part of this patch in previous version, they are not answered and this version is dropping the testpmd part.

The tunnel offload API allows application to place tunnel offload elements at any valid location in a flow rule.

Current testpmd code places tunnel offload items
at the beginning of pattern array and tunnel offload actions at the beginning of actions array.

The testpmd patch in v1 & v2 changed location of tunnel offload elements in a flow rule.

Quoted 3 lines

Is it safe to remove the testpmd part? If so why was the changes for at first place?

That patch was not a fix - it emphasized general usage of the tunnel offload API. Current testpmd code works fine.

Quoted 3 lines

And can you please reply to the questions on the testpmd patch for the record?

I'll add my replies.

Quoted 2 lines

Thanks,
Ferruh

Regards,
Gregory

Quoted 6 lines

Quoted 4 lines

The were some questions around testpmd part of this patch in previous version, they are not answered and this version is dropping the testpmd part.

The tunnel offload API allows application to place tunnel offload elements

at any valid location in a flow rule.

How PMD should detect the tunnel offload elements?

And which API are we talking about, is there enough documentation in the API about the location of the tunnel offload elements, or should we clarify it more?

Quoted 2 lines

Current testpmd code places tunnel offload items at the beginning of pattern array and tunnel offload actions at the beginning of actions array.

Got it, so this patch is removing false expectation (about the location of the tunnel offload elements in flow rule) in the PMD, right?

As far as I understand testpmd already satisfies this false expectation, so the problem should not be visible with testpmd.
Was there a visible user impact, like any application failing because of this false expectation, or is this theoretical fix to be correct with API contract?

btw, I can see 'MLX5_RTE_FLOW_ITEM_TYPE_TUNNEL' still checked if it in the first location of the items (items[0].type), in 'flow_dv_validate()', 'mlx5_flow_dv.c'
https://git.dpdk.org/dpdk/tree/drivers/net/mlx5/mlx5_flow_dv.c?h=v21.0
5-rc1#n6298
Can you please confirm that this is expected?

Quoted 1 line

The testpmd patch in v1 & v2 changed location of tunnel offload elements

in a flow rule.

Quoted 6 lines

Quoted 4 lines

Is it safe to remove the testpmd part? If so why was the changes for at first place?

That patch was not a fix - it emphasized general usage of the tunnel

offload API.

Quoted 14 lines

Current testpmd code works fine.

Quoted 3 lines

And can you please reply to the questions on the testpmd patch for the record?

I'll add my replies.

Quoted 2 lines

Thanks,
Ferruh

Regards,
Gregory

Quoted 4 lines

btw, I can see 'MLX5_RTE_FLOW_ITEM_TYPE_TUNNEL' still checked if it in the first location of the items (items[0].type), in 'flow_dv_validate()', 'mlx5_flow_dv.c'

https://git.dpdk.org/dpdk/tree/drivers/net/mlx5/mlx5_flow_dv.c?h=v21.0

Quoted 3 lines

5-rc1#n6298
Can you please confirm that this is expected?

The items variable in that function iterates on pattern array:

for (; items->type != RTE_FLOW_ITEM_TYPE_END; items++) {

In this scenario,

case MLX5_RTE_FLOW_ITEM_TYPE_TUNNEL:
if (items[0].type !=

        (typeof(items[0].type))MLX5_RTE_FLOW_ITEM_TYPE_TUNNEL)

compares items with itself.

-----Original Message-----
From: Gregory Etelson <[email protected]>
Sent: Thursday, May 6, 2021 12:58
To: [email protected]
Cc: Gregory Etelson <[email protected]>; Matan Azrad <[email protected]>; Ori Kam <[email protected]>; Raslan Darawsheh <[email protected]>; [email protected]; [email protected]; Slava Ovsiienko <[email protected]>; Shahaf Shuler <[email protected]>
Subject: [PATCH v4] net/mlx5: fix tunnel offload private items location

Tunnel offload API requires application to query PMD for specific flow items and actions. Application uses these PMD specific elements to build flow rules according to the tunnel offload model.
The model does not restrict private elements location in a flow rule, but the current MLX5 PMD implementation expects that tunnel offload rule will begin with PMD specific elements.
The patch removes that placement limitation.

Cc [email protected]

Fixes 4ec6360de37d ("net/mlx5: implement tunnel offload")

Signed-off-by Gregory Etelson <[email protected]>

Acked-by Viacheslav Ovsiienko <[email protected]>

---
v2: Update the patch comment.
v3: Remove testpmd patch from the series.
v4: Remove redundant verifications in flow_dv_validate.

---
 drivers/net/mlx5/mlx5_flow.c    | 48 ++++++++++++------
 drivers/net/mlx5/mlx5_flow.h    | 46 ++++++++++-------
 drivers/net/mlx5/mlx5_flow_dv.c | 88 ++++++++++++++++-----------------
 3 files changed, 102 insertions(+), 80 deletions(-)

drivers/net/mlx5/mlx5_flow.c +1 -0

index 3194cd5633..f464271d42 100644
@@ -50,6 +50,7 @@ flow_tunnel_add_default_miss(struct rte_eth_dev
 *dev,
 			     const struct rte_flow_attr *attr,
 			     const struct rte_flow_action *app_actions,
 			     uint32_t flow_idx,
+			     const struct mlx5_flow_tunnel *tunnel,
 			     struct tunnel_default_miss_ctx *ctx,
 			     struct rte_flow_error *error);

static struct mlx5_flow_tunnel *

drivers/net/mlx5/mlx5_flow.c +3 -11

@@ -5958,22 +5959,14 @@ flow_create_split_outer(struct rte_eth_dev
 *dev,
 	return ret;
 }
 
-static struct mlx5_flow_tunnel *
-flow_tunnel_from_rule(struct rte_eth_dev *dev,
-		      const struct rte_flow_attr *attr,
-		      const struct rte_flow_item items[],
-		      const struct rte_flow_action actions[])
+static inline struct mlx5_flow_tunnel * flow_tunnel_from_rule(const
+struct mlx5_flow *flow)
 {
 	struct mlx5_flow_tunnel *tunnel;
 
 #pragma GCC diagnostic push
 #pragma GCC diagnostic ignored "-Wcast-qual"
-	if (is_flow_tunnel_match_rule(dev, attr, items, actions))
-		tunnel = (struct mlx5_flow_tunnel *)items[0].spec;
-	else if (is_flow_tunnel_steer_rule(dev, attr, items, actions))
-		tunnel = (struct mlx5_flow_tunnel *)actions[0].conf;
-	else
-		tunnel = NULL;
+	tunnel = (typeof(tunnel))flow->tunnel;
 #pragma GCC diagnostic pop
 

drivers/net/mlx5/mlx5_flow.c +2 -3

 	return tunnel;

@@ -6168,12 +6161,11 @@ flow_list_create(struct rte_eth_dev *dev,
 uint32_t *list,
 					      error);
 		if (ret < 0)
 			goto error;
-		if (is_flow_tunnel_steer_rule(dev, attr,
-					      buf->entry[i].pattern,
-					      p_actions_rx)) {
+		if (is_flow_tunnel_steer_rule(wks->flows[0].tof_type)) {
 			ret = flow_tunnel_add_default_miss(dev, flow, attr,
 							   p_actions_rx,
 							   idx,
+							   wks-
 >flows[0].tunnel,
 							   &default_miss_ctx,

drivers/net/mlx5/mlx5_flow.c +1 -1

 							   error);
 			if (ret < 0) {

@@ -6237,7 +6229,7 @@ flow_list_create(struct rte_eth_dev *dev,
 uint32_t *list,
 	}
 	flow_rxq_flags_set(dev, flow);
 	rte_free(translated_actions);
-	tunnel = flow_tunnel_from_rule(dev, attr, items, actions);
+	tunnel = flow_tunnel_from_rule(wks->flows);
 	if (tunnel) {
 		flow->tunnel = 1;

drivers/net/mlx5/mlx5_flow.c +22 -1

 		flow->tunnel_id = tunnel->tunnel_id;

@@ -8152,6 +8144,28 @@ int rte_pmd_mlx5_sync_flow(uint16_t port_id,
 uint32_t domains)
 	return ret;
 }
 
+const struct mlx5_flow_tunnel *
+mlx5_get_tof(const struct rte_flow_item *item,
+	     const struct rte_flow_action *action,
+	     enum mlx5_tof_rule_type *rule_type) {
+	for (; item->type != RTE_FLOW_ITEM_TYPE_END; item++) {
+		if (item->type == (typeof(item->type))
+				  MLX5_RTE_FLOW_ITEM_TYPE_TUNNEL) {
+			*rule_type =
 MLX5_TUNNEL_OFFLOAD_MATCH_RULE;
+			return flow_items_to_tunnel(item);
+		}
+	}
+	for (; action->conf != RTE_FLOW_ACTION_TYPE_END; action++) {
+		if (action->type == (typeof(action->type))
+
 MLX5_RTE_FLOW_ACTION_TYPE_TUNNEL_SET) {
+			*rule_type = MLX5_TUNNEL_OFFLOAD_SET_RULE;
+			return flow_actions_to_tunnel(action);
+		}
+	}
+	return NULL;
+}
+
 /**
  * tunnel offload functionalilty is defined for DV environment only
  */

@@ -8182,13 +8196,13 @@ flow_tunnel_add_default_miss(struct
 rte_eth_dev *dev,
 			     const struct rte_flow_attr *attr,
 			     const struct rte_flow_action *app_actions,
 			     uint32_t flow_idx,
+			     const struct mlx5_flow_tunnel *tunnel,
 			     struct tunnel_default_miss_ctx *ctx,
 			     struct rte_flow_error *error)
 {
 	struct mlx5_priv *priv = dev->data->dev_private;
 	struct mlx5_flow *dev_flow;
 	struct rte_flow_attr miss_attr = *attr;
-	const struct mlx5_flow_tunnel *tunnel = app_actions[0].conf;
 	const struct rte_flow_item miss_items[2] = {
 		{

drivers/net/mlx5/mlx5_flow.c +1 -0

 			.type = RTE_FLOW_ITEM_TYPE_ETH,

@@ -8274,6 +8288,7 @@ flow_tunnel_add_default_miss(struct
 rte_eth_dev *dev,
 	dev_flow->flow = flow;
 	dev_flow->external = true;
 	dev_flow->tunnel = tunnel;
+	dev_flow->tof_type = MLX5_TUNNEL_OFFLOAD_MISS_RULE;
 	/* Subflow object was created, we must include one in the list. */
 	SILIST_INSERT(&flow->dev_handles, dev_flow->handle_idx,

drivers/net/mlx5/mlx5_flow.c +1 -0

 		      dev_flow->handle, next);

@@ -8887,6 +8902,7 @@ flow_tunnel_add_default_miss(__rte_unused
 struct rte_eth_dev *dev,
 			     __rte_unused const struct rte_flow_attr *attr,
 			     __rte_unused const struct rte_flow_action
 *actions,
 			     __rte_unused uint32_t flow_idx,
+			     __rte_unused const struct mlx5_flow_tunnel
 *tunnel,

__rte_unused struct tunnel_default_miss_ctx
*ctx,
__rte_unused struct rte_flow_error *error) { diff
--git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h index 5365699426..04c8806bf6 100644

drivers/net/mlx5/mlx5_flow.h +0 -0

@@ -819,6 +819,16 @@ struct mlx5_flow_verbs_workspace {
 /** Maximal number of device sub-flows supported. */  #define

MLX5_NUM_MAX_DEV_FLOWS 32

drivers/net/mlx5/mlx5_flow.h +17 -14

+/**
+ * tunnel offload rules type
+ */
+enum mlx5_tof_rule_type {
+	MLX5_TUNNEL_OFFLOAD_NONE = 0,
+	MLX5_TUNNEL_OFFLOAD_SET_RULE,
+	MLX5_TUNNEL_OFFLOAD_MATCH_RULE,
+	MLX5_TUNNEL_OFFLOAD_MISS_RULE,
+};
+
 /** Device flow structure. */
 __extension__
 struct mlx5_flow {

@@ -854,6 +864,7 @@ struct mlx5_flow {
 	struct mlx5_flow_handle *handle;
 	uint32_t handle_idx; /* Index of the mlx5 flow handle memory. */
 	const struct mlx5_flow_tunnel *tunnel;
+	enum mlx5_tof_rule_type tof_type;
 };
 
 /* Flow meter state. */

@@ -949,10 +960,10 @@ mlx5_tunnel_hub(struct rte_eth_dev *dev)  }
 
 static inline bool
-is_tunnel_offload_active(struct rte_eth_dev *dev)
+is_tunnel_offload_active(const struct rte_eth_dev *dev)
 {
 #ifdef HAVE_IBV_FLOW_DV_SUPPORT
-	struct mlx5_priv *priv = dev->data->dev_private;
+	const struct mlx5_priv *priv = dev->data->dev_private;
 	return !!priv->config.dv_miss_info;
 #else
 	RTE_SET_USED(dev);

@@ -961,23 +972,15 @@ is_tunnel_offload_active(struct rte_eth_dev
 *dev)  }
 
 static inline bool
-is_flow_tunnel_match_rule(__rte_unused struct rte_eth_dev *dev,
-			  __rte_unused const struct rte_flow_attr *attr,
-			  __rte_unused const struct rte_flow_item items[],
-			  __rte_unused const struct rte_flow_action
 actions[])
+is_flow_tunnel_match_rule(enum mlx5_tof_rule_type tof_rule_type)
 {
-	return (items[0].type == (typeof(items[0].type))
-				 MLX5_RTE_FLOW_ITEM_TYPE_TUNNEL);
+	return tof_rule_type == MLX5_TUNNEL_OFFLOAD_MATCH_RULE;
 }
 
 static inline bool
-is_flow_tunnel_steer_rule(__rte_unused struct rte_eth_dev *dev,
-			  __rte_unused const struct rte_flow_attr *attr,
-			  __rte_unused const struct rte_flow_item items[],
-			  __rte_unused const struct rte_flow_action
 actions[])
+is_flow_tunnel_steer_rule(enum mlx5_tof_rule_type tof_rule_type)
 {
-	return (actions[0].type == (typeof(actions[0].type))
-
 MLX5_RTE_FLOW_ACTION_TYPE_TUNNEL_SET);
+	return tof_rule_type == MLX5_TUNNEL_OFFLOAD_SET_RULE;

}

static inline const struct mlx5_flow_tunnel * @@ -1273,11 +1276,10 @@
struct flow_grp_info {

static inline bool
tunnel_use_standard_attr_group_translate

drivers/net/mlx5/mlx5_flow.h +4 -5

-		    (struct rte_eth_dev *dev,
-		     const struct mlx5_flow_tunnel *tunnel,
+		    (const struct rte_eth_dev *dev,
 		     const struct rte_flow_attr *attr,
-		     const struct rte_flow_item items[],
-		     const struct rte_flow_action actions[])
+		     const struct mlx5_flow_tunnel *tunnel,
+		     enum mlx5_tof_rule_type tof_rule_type)
 {
 	bool verdict;

@@ -1293,7 +1295,7 @@ tunnel_use_standard_attr_group_translate
 		 * method
 		 */
 		verdict = !attr->group &&
-			  is_flow_tunnel_steer_rule(dev, attr, items,
 actions);
+			  is_flow_tunnel_steer_rule(tof_rule_type);
 	} else {
 		/*

drivers/net/mlx5/mlx5_flow.h +0 -0

 		 * non-tunnel group translation uses standard method for

@@ -1681,4 +1683,10 @@ int mlx5_flow_create_def_policy(struct

rte_eth_dev *dev); void mlx5_flow_destroy_def_policy(struct rte_eth_dev *dev); void flow_drv_rxq_flags_set(struct rte_eth_dev *dev,

drivers/net/mlx5/mlx5_flow.h +6 -0

 		       struct mlx5_flow_handle *dev_handle);
+const struct mlx5_flow_tunnel *
+mlx5_get_tof(const struct rte_flow_item *items,
+	     const struct rte_flow_action *actions,
+	     enum mlx5_tof_rule_type *rule_type);
+
+
 #endif /* RTE_PMD_MLX5_FLOW_H_ */

(quoted diff) +0 -0

b/drivers/net/mlx5/mlx5_flow_dv.c index 70e8d0b113..10ca342edc 100644

drivers/net/mlx5/mlx5_flow_dv.c +2 -0

@@ -6627,10 +6627,12 @@ flow_dv_validate(struct rte_eth_dev *dev,
 const struct rte_flow_attr *attr,
 	uint32_t rw_act_num = 0;
 	uint64_t is_root;
 	const struct mlx5_flow_tunnel *tunnel;
+	enum mlx5_tof_rule_type tof_rule_type;
 	struct flow_grp_info grp_info = {
 		.external = !!external,
 		.transfer = !!attr->transfer,
 		.fdb_def_rule = !!priv->fdb_def_rule,
+		.std_tbl_fix = true,
 	};
 	const struct rte_eth_hairpin_conf *conf;

const struct rte_flow_item *rule_items = items; @@ -6638,23
+6640,22 @@ flow_dv_validate(struct rte_eth_dev *dev, const struct rte_flow_attr *attr,

drivers/net/mlx5/mlx5_flow_dv.c +8 -9

 	if (items == NULL)
 		return -1;
-	if (is_flow_tunnel_match_rule(dev, attr, items, actions)) {
-		tunnel = flow_items_to_tunnel(items);
-		action_flags |= MLX5_FLOW_ACTION_TUNNEL_MATCH |
-				MLX5_FLOW_ACTION_DECAP;
-	} else if (is_flow_tunnel_steer_rule(dev, attr, items, actions)) {
-		tunnel = flow_actions_to_tunnel(actions);
-		action_flags |= MLX5_FLOW_ACTION_TUNNEL_SET;
-	} else {
-		tunnel = NULL;
+	tunnel = is_tunnel_offload_active(dev) ?
+		 mlx5_get_tof(items, actions, &tof_rule_type) : NULL;
+	if (tunnel) {
+		if (priv->representor)
+			return rte_flow_error_set
+				(error, ENOTSUP,
+				 RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+				 NULL, "decap not supported for VF

representor");

drivers/net/mlx5/mlx5_flow_dv.c +3 -0

+		if (tof_rule_type == MLX5_TUNNEL_OFFLOAD_SET_RULE)
+			action_flags |= MLX5_FLOW_ACTION_TUNNEL_SET;
+		else if (tof_rule_type ==

MLX5_TUNNEL_OFFLOAD_MATCH_RULE)

drivers/net/mlx5/mlx5_flow_dv.c +1 -0

+			action_flags |=

MLX5_FLOW_ACTION_TUNNEL_MATCH |

drivers/net/mlx5/mlx5_flow_dv.c +2 -0

+					MLX5_FLOW_ACTION_DECAP;
+		grp_info.std_tbl_fix =

tunnel_use_standard_attr_group_translate

drivers/net/mlx5/mlx5_flow_dv.c +1 -3

+					(dev, attr, tunnel, tof_rule_type);
 	}
-	if (tunnel && priv->representor)
-		return rte_flow_error_set(error, ENOTSUP,
-

RTE_FLOW_ERROR_TYPE_UNSPECIFIED, NULL,

drivers/net/mlx5/mlx5_flow_dv.c +0 -4

-					  "decap not supported "
-					  "for VF representor");
-	grp_info.std_tbl_fix = tunnel_use_standard_attr_group_translate
-				(dev, tunnel, attr, items, actions);
 	ret = flow_dv_validate_attributes(dev, tunnel, attr, &grp_info,

error);

drivers/net/mlx5/mlx5_flow_dv.c +0 -3

 	if (ret < 0)
 		return ret;

@@ -6668,15 +6669,6 @@ flow_dv_validate(struct rte_eth_dev *dev,
 const struct rte_flow_attr *attr,
 
 RTE_FLOW_ERROR_TYPE_ITEM,
 						  NULL, "item not
 supported");
 		switch (type) {
-		case MLX5_RTE_FLOW_ITEM_TYPE_TUNNEL:
-			if (items[0].type != (typeof(items[0].type))
-

MLX5_RTE_FLOW_ITEM_TYPE_TUNNEL)

drivers/net/mlx5/mlx5_flow_dv.c +0 -3

-				return rte_flow_error_set
-						(error, EINVAL,
-

RTE_FLOW_ERROR_TYPE_ITEM,

drivers/net/mlx5/mlx5_flow_dv.c +5 -3

-						NULL, "MLX5 private items "
-						"must be the first");
-			break;
 		case RTE_FLOW_ITEM_TYPE_VOID:
 			break;
 		case RTE_FLOW_ITEM_TYPE_PORT_ID:

@@ -6975,6 +6967,11 @@ flow_dv_validate(struct rte_eth_dev *dev,
 const struct rte_flow_attr *attr,
 			if (ret < 0)
 				return ret;
 			break;
+		case MLX5_RTE_FLOW_ITEM_TYPE_TUNNEL:
+			/* tunnel offload item was processed before
+			 * list it here as a supported type
+			 */
+			break;
 		default:
 			return rte_flow_error_set(error, ENOTSUP,

RTE_FLOW_ERROR_TYPE_ITEM,

drivers/net/mlx5/mlx5_flow_dv.c +0 -11

@@ -7516,17 +7513,6 @@ flow_dv_validate(struct rte_eth_dev *dev,
 const struct rte_flow_attr *attr,
 			action_flags |= MLX5_FLOW_ACTION_SAMPLE;
 			++actions_n;
 			break;
-		case MLX5_RTE_FLOW_ACTION_TYPE_TUNNEL_SET:
-			if (actions[0].type != (typeof(actions[0].type))
-
 	MLX5_RTE_FLOW_ACTION_TYPE_TUNNEL_SET)
-				return rte_flow_error_set
-						(error, EINVAL,
-
 	RTE_FLOW_ERROR_TYPE_ACTION,
-						NULL, "MLX5 private action "
-						"must be the first");
-
-			action_flags |= MLX5_FLOW_ACTION_TUNNEL_SET;
-			break;

drivers/net/mlx5/mlx5_flow_dv.c +0 -0

 		case RTE_FLOW_ACTION_TYPE_MODIFY_FIELD:
 			ret = flow_dv_validate_action_modify_field(dev,

action_flags,

drivers/net/mlx5/mlx5_flow_dv.c +5 -0

@@ -7551,6 +7537,11 @@ flow_dv_validate(struct rte_eth_dev *dev,
 const struct rte_flow_attr *attr,
 				return ret;
 			action_flags |= MLX5_FLOW_ACTION_CT;
 			break;
+		case MLX5_RTE_FLOW_ACTION_TYPE_TUNNEL_SET:
+			/* tunnel offload action was processed before
+			 * list it here as a supported type
+			 */
+			break;
 		default:
 			return rte_flow_error_set(error, ENOTSUP,

RTE_FLOW_ERROR_TYPE_ACTION,

drivers/net/mlx5/mlx5_flow_dv.c +13 -6

@@ -12035,13 +12026,14 @@ flow_dv_translate(struct rte_eth_dev *dev,
 	int tmp_actions_n = 0;
 	uint32_t table;
 	int ret = 0;
-	const struct mlx5_flow_tunnel *tunnel;
+	const struct mlx5_flow_tunnel *tunnel = NULL;
 	struct flow_grp_info grp_info = {
 		.external = !!dev_flow->external,
 		.transfer = !!attr->transfer,
 		.fdb_def_rule = !!priv->fdb_def_rule,
 		.skip_scale = dev_flow->skip_scale &
 			(1 << MLX5_SCALE_FLOW_GROUP_BIT),
+		.std_tbl_fix = true,
 	};
 	const struct rte_flow_item *head_item = items;
 

@@ -12057,15 +12049,21 @@ flow_dv_translate(struct rte_eth_dev *dev,
 
 MLX5DV_FLOW_TABLE_TYPE_NIC_RX;
 	/* update normal path action resource into last index of array */
 	sample_act = &mdest_res.sample_act[MLX5_MAX_DEST_NUM -
 1];
-	tunnel = is_flow_tunnel_match_rule(dev, attr, items, actions) ?
-		 flow_items_to_tunnel(items) :
-		 is_flow_tunnel_steer_rule(dev, attr, items, actions) ?
-		 flow_actions_to_tunnel(actions) :
-		 dev_flow->tunnel ? dev_flow->tunnel : NULL;
+	if (is_tunnel_offload_active(dev)) {
+		if (dev_flow->tunnel) {
+			RTE_VERIFY(dev_flow->tof_type ==
+				   MLX5_TUNNEL_OFFLOAD_MISS_RULE);
+			tunnel = dev_flow->tunnel;
+		} else {
+			tunnel = mlx5_get_tof(items, actions,
+					      &dev_flow->tof_type);
+			dev_flow->tunnel = tunnel;
+		}
+		grp_info.std_tbl_fix =

tunnel_use_standard_attr_group_translate

drivers/net/mlx5/mlx5_flow_dv.c +1 -0

+					(dev, attr, tunnel, dev_flow-

Quoted 1 line

tof_type);

drivers/net/mlx5/mlx5_flow_dv.c +1 -0

+	}
 	mhdr_res->ft_type = attr->egress ?

MLX5DV_FLOW_TABLE_TYPE_NIC_TX :

MLX5DV_FLOW_TABLE_TYPE_NIC_RX;

drivers/net/mlx5/mlx5_flow_dv.c +1 -4

-	grp_info.std_tbl_fix = tunnel_use_standard_attr_group_translate
-				(dev, tunnel, attr, items, actions);
 	ret = mlx5_flow_group_to_table(dev, tunnel, attr->group, &table,
 				       &grp_info, error);
 	if (ret)

@@ -12075,7 +12073,7 @@ flow_dv_translate(struct rte_eth_dev *dev,
 		mhdr_res->ft_type = MLX5DV_FLOW_TABLE_TYPE_FDB;
 	/* number of actions must be set to 0 in case of dirty stack. */
 	mhdr_res->actions_num = 0;
-	if (is_flow_tunnel_match_rule(dev, attr, items, actions)) {
+	if (is_flow_tunnel_match_rule(dev_flow->tof_type)) {
 		/*
 		 * do not add decap action if match rule drops packet
 		 * HW rejects rules with decap & drop
--

2.31.1

Hello Ferruh,

The patch has failed ci/Intel-compilation test.
(http://mails.dpdk.org/archives/test-report/2021-May/193327.html)
I've checked that with Thomas. He confirmed that was a known fault and should not affect the current patch.
Can we proceed with the patch integration ?

Thank you.

Regards,
Gregory

Quoted 29 lines

-----Original Message-----
From: Gregory Etelson <[email protected]>
Sent: Thursday, May 6, 2021 12:58
To: [email protected]
Cc: Gregory Etelson <[email protected]>; Matan Azrad <[email protected]>; Ori Kam <[email protected]>; Raslan Darawsheh <[email protected]>; [email protected]; [email protected]; Slava Ovsiienko <[email protected]>; Shahaf Shuler <[email protected]>
Subject: [PATCH v4] net/mlx5: fix tunnel offload private items location

Tunnel offload API requires application to query PMD for specific flow items and actions. Application uses these PMD specific elements to build flow rules according to the tunnel offload model.
The model does not restrict private elements location in a flow rule, but the current MLX5 PMD implementation expects that tunnel offload rule will begin with PMD specific elements.
The patch removes that placement limitation.

Cc [email protected]

Fixes 4ec6360de37d ("net/mlx5: implement tunnel offload")

Signed-off-by Gregory Etelson <[email protected]>

Acked-by Viacheslav Ovsiienko <[email protected]>

---
v2: Update the patch comment.
v3: Remove testpmd patch from the series.
v4: Remove redundant verifications in flow_dv_validate.

Tunnel offload API requires application to query PMD for specific flow items and actions. Application uses these PMD specific elements to build flow rules according to the tunnel offload model.
The model does not restrict private elements location in a flow rule, but the current MLX5 PMD implementation expects that tunnel offload rule will begin with PMD specific elements.
The patch removes that placement limitation.

Cc [email protected]

Fixes 4ec6360de37d ("net/mlx5: implement tunnel offload")

Signed-off-by Gregory Etelson <[email protected]>

Acked-by Viacheslav Ovsiienko <[email protected]>