diff mbox series

[v2,1/2] net/mlx5: fix tunnel offload private items location

Message ID 20210425155722.32477-1-getelson@nvidia.com (mailing list archive)
State Superseded, archived
Delegated to: Ferruh Yigit
Headers
Series [v2,1/2] net/mlx5: fix tunnel offload private items location |

Checks

Context Check Description
ci/checkpatch success coding style OK

Commit Message

Gregory Etelson April 25, 2021, 3:57 p.m. UTC 
  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: stable@dpdk.org

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

Signed-off-by: Gregory Etelson <getelson@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
---
 drivers/net/mlx5/mlx5_flow.c    | 48 ++++++++++++++++++---------
 drivers/net/mlx5/mlx5_flow.h    | 44 ++++++++++++++-----------
 drivers/net/mlx5/mlx5_flow_dv.c | 58 +++++++++++++++++++--------------
 3 files changed, 90 insertions(+), 60 deletions(-)

Comments

Thomas Monjalon April 25, 2021, 4:28 p.m. UTC | #1 
Dim 25 avr 2021, à 17:57, Gregory Etelson a écrit :
> 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: stable@dpdk.org
> 
> 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?
Gregory Etelson April 25, 2021, 5:01 p.m. UTC | #2 
Hello Thomas,
 
> Dim 25 avr 2021, à 17:57, Gregory Etelson a écrit :
> > 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: stable@dpdk.org
> >
> > 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?

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.

Regards,
Gregory
Thomas Monjalon April 25, 2021, 5:07 p.m. UTC | #3 
Dim 25 avr 2021, à 19:01, Gregory Etelson a écrit :
> Hello Thomas,
>  
> > Dim 25 avr 2021, à 17:57, Gregory Etelson a écrit :
> > > 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: stable@dpdk.org
> > >
> > > 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?
> 
> 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.
Ferruh Yigit April 26, 2021, 7:54 a.m. UTC | #4 
On 4/25/2021 6:07 PM, Thomas Monjalon wrote:
> Dim 25 avr 2021, à 19:01, Gregory Etelson a écrit :
>> Hello Thomas,
>>   
>>> Dim 25 avr 2021, à 17:57, Gregory Etelson a écrit :
>>>> 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: stable@dpdk.org
>>>>
>>>> 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?
>>
>> 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.
Gregory Etelson April 27, 2021, 9:27 a.m. UTC | #5 
Hello Ferruh,

[snip]

> 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
 
> 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.

Regards,
Gregory
Gregory Etelson April 29, 2021, 7:44 a.m. UTC | #6 
Hello Ferruh,

> [snip]
> 
> > 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
> 
> > 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.

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

Regards,
Gregory
Ferruh Yigit April 30, 2021, 1:37 p.m. UTC | #7 
On 4/29/2021 8:44 AM, Gregory Etelson wrote:
> Hello Ferruh,
> 
>> [snip]
>>
>>> 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
>>
>>> 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.
> 
> There was no progress with this patch. 
> Is it scheduled for 21.05 ?
> 

There were some questions on the v1 of the patch not answered, let me put them
back again to v2.
Gregory Etelson May 4, 2021, 9:20 a.m. UTC | #8 
Hello Ferruh,

[:snip:]

> 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.

Mlx5 PMD and testpmd patches are not coupled.
The PMD patch fixes a bug in tunnel offload implementation and
the testpmd patch emphasizes general usage of the tunnel offload API.
The testpmd patch is not at fix - the current code works fine.
I'll remove the testpmd patch in v3.

Regards,
Gregory
diff mbox series

Patch

diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 84463074a5..fcc82ce9d4 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -51,6 +51,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 *
@@ -5463,22 +5464,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
 
 	return tunnel;
@@ -5672,12 +5665,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,
 							   error);
 			if (ret < 0) {
@@ -5741,7 +5733,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;
 		flow->tunnel_id = tunnel->tunnel_id;
@@ -7459,6 +7451,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
  */
@@ -7489,13 +7503,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] = {
 		{
 			.type = RTE_FLOW_ITEM_TYPE_ETH,
@@ -7581,6 +7595,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,
 		      dev_flow->handle, next);
@@ -8192,6 +8207,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 ec673c29ab..61f40adc25 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -783,6 +783,16 @@  struct mlx5_flow_verbs_workspace {
 /** Maximal number of device sub-flows supported. */
 #define MLX5_NUM_MAX_DEV_FLOWS 32
 
+/**
+ * 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 {
@@ -818,6 +828,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. */
@@ -1029,10 +1040,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);
@@ -1041,23 +1052,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 *
@@ -1299,11 +1302,10 @@  struct flow_grp_info {
 
 static inline bool
 tunnel_use_standard_attr_group_translate
-		    (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;
 
@@ -1319,7 +1321,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 {
 		/*
 		 * non-tunnel group translation uses standard method for
@@ -1580,6 +1582,10 @@  int mlx5_flow_os_init_workspace_once(void);
 void *mlx5_flow_os_get_specific_workspace(void);
 int mlx5_flow_os_set_specific_workspace(struct mlx5_flow_workspace *data);
 void mlx5_flow_os_release_workspace(void);
+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_ */
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index e65cc13bd6..3b16f75743 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -6100,32 +6100,33 @@  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;
 
 	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");
+		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)
+			action_flags |= MLX5_FLOW_ACTION_TUNNEL_MATCH |
+					MLX5_FLOW_ACTION_DECAP;
+		grp_info.std_tbl_fix = tunnel_use_standard_attr_group_translate
+					(dev, attr, tunnel, tof_rule_type);
 	}
-	if (tunnel && priv->representor)
-		return rte_flow_error_set(error, ENOTSUP,
-					  RTE_FLOW_ERROR_TYPE_UNSPECIFIED, NULL,
-					  "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);
 	if (ret < 0)
 		return ret;
@@ -10909,13 +10910,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,
 	};
 
 	if (!wks)
@@ -10930,15 +10932,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
+					(dev, attr, tunnel, dev_flow->tof_type);
+	}
 	mhdr_res->ft_type = attr->egress ? MLX5DV_FLOW_TABLE_TYPE_NIC_TX :
 					   MLX5DV_FLOW_TABLE_TYPE_NIC_RX;
-	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)
@@ -10948,7 +10956,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