[v3] net/mlx5: fix tunnel offload private items location

Message ID 20210502080817.17737-1-getelson@nvidia.com (mailing list archive)
State Superseded, archived
Delegated to: Raslan Darawsheh
Headers
Series [v3] net/mlx5: fix tunnel offload private items location |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation warning apply issues
ci/iol-intel-Functional success Functional Testing PASS
ci/iol-intel-Performance success Performance Testing PASS
ci/iol-mellanox-Performance success Performance Testing PASS
ci/iol-abi-testing success Testing PASS
ci/iol-testing success Testing PASS

Commit Message

Gregory Etelson May 2, 2021, 8:08 a.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.

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    | 46 +++++++++++++++-----------
 drivers/net/mlx5/mlx5_flow_dv.c | 58 +++++++++++++++++++--------------
 3 files changed, 92 insertions(+), 60 deletions(-)
  

Comments

Raslan Darawsheh May 4, 2021, 8:10 a.m. UTC | #1
Hi,

> -----Original Message-----
> From: Gregory Etelson <getelson@nvidia.com>
> Sent: Sunday, May 2, 2021 11:08 AM
> To: dev@dpdk.org
> Cc: Gregory Etelson <getelson@nvidia.com>; Matan Azrad
> <matan@nvidia.com>; Ori Kam <orika@nvidia.com>; Raslan Darawsheh
> <rasland@nvidia.com>; stable@dpdk.org; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Shahaf Shuler <shahafs@nvidia.com>
> 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: 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>

Patch applied to next-net-mlx,

Kindest regards
Raslan Darawsheh
  
Ferruh Yigit May 4, 2021, 8:20 a.m. UTC | #2
On 5/2/2021 9:08 AM, Gregory Etelson wrote:
> 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: 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>


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
  
Gregory Etelson May 4, 2021, 9:12 a.m. UTC | #3
Hello Ferruh,

[:snip:]

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

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

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

I'll add my replies.

> Thanks,
> Ferruh

Regards,
Gregory
  
Ferruh Yigit May 5, 2021, 5:45 p.m. UTC | #4
On 5/4/2021 10:12 AM, Gregory Etelson wrote:
> Hello Ferruh,
> 
> [:snip:]
> 
>> 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. 

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?

> 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.05-rc1#n6298
Can you please confirm that this is expected?

> The testpmd patch in v1 & v2 changed location of tunnel offload elements in a flow rule.
> 
>> 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.
> 
>> And can you please reply to the questions on the testpmd patch for the
>> record?
>>
> 
> I'll add my replies.
> 
>> Thanks,
>> Ferruh
> 
> Regards,
> Gregory
>
  
Gregory Etelson May 6, 2021, 6:08 a.m. UTC | #5
Hello Ferruh,

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

Flow elements in tunnel offload rule can be logically divided into two parts:
- application elements that reflect application logic
- tunnel offload related elements. These flow elements are selected by PMD 
to implement tunnel offload with respect to underlying hardware.
Application obtains these actions and items from PMD with 
rte_flow_tunnel_decap_and_set() and rte_flow_tunnel_match().
Application combines both parts into a flow rule and sends it to PMD.

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

The tunnel offload API was introduced here:
commit 9ec0f97e02e1 ("ethdev: add tunnel offload model").
There is a detailed explanation with examples how the API works.
 
> > 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?
> 

Correct. Location of flow elements supplied by PMD in a rule is not important. 

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

There is no issue with the testpmd code. 
The bug was discovered by OVS.
 
> 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?
>

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.

> > The testpmd patch in v1 & v2 changed location of tunnel offload elements
> in a flow rule.
> >
> >> 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.
> >
> >> And can you please reply to the questions on the testpmd patch for
> >> the record?
> >>
> >
> > I'll add my replies.
> >
> >> Thanks,
> >> Ferruh
> >
> > Regards,
> > Gregory
> >
  
Gregory Etelson May 6, 2021, 7:40 a.m. UTC | #6
Hello Ferruh,

[:snip:]

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

I'll post an updated patch.

Regards,
Gregory
  
Arthas May 6, 2021, 7:59 a.m. UTC | #7
Hareware:&nbsp; CX5/CX6 DX + Intel(R) Xeon(R) Platinum 9242 CPU @ 2.30GHz&nbsp;&nbsp;DPDK version: 19.11.8/20.11/21.05-rc1&amp;2


testpmd with case:
testpmd&gt; flow create 0 ingress pattern eth / ipv4 / udp dst is 53 / end actions count / drop / end
testpmd&gt; flow create 0 ingress pattern eth / ipv4 / udp src is 53 / end actions count / drop / end
testpmd&gt; flow create 0 ingress pattern eth / ipv4 / tcp / end actions count /drop end

testpmd&gt; flow list 0
ID	Group	Prio	Attr	Rule
0	0	0	i--	ETH IPV4 UDP =&gt; COUNT DROP
1	0	0	i--	ETH IPV4 UDP =&gt; COUNT DROP
2	0	0	i--	ETH IPV4 UDP =&gt; COUNT DROP

or
testpmd&gt; flow create 0 ingress pattern eth / ipv4 / udp dst is 53 / end actions count / rss / end
testpmd&gt; flow create 0 ingress pattern eth / ipv4 / udp src is 53 / end actions count / rss / end
testpmd&gt; flow create 0 ingress pattern eth / ipv4 / udp / end actions count / rss / end
testpmd&gt; flow list 0
ID	Group	Prio	Attr	Rule
0	0	0	i--	ETH IPV4 UDP =&gt; COUNT RSS
1	0	0	i--	ETH IPV4 UDP =&gt; COUNT RSS
2	0	0	i--	ETH IPV4 UDP =&gt; COUNT RSS
testpmd&gt;&nbsp;



as soon as NIC create more than 1 flow ,&nbsp; CX5/CX6-dx NIC will increment 'rx_phy_discard_packets'.
only 1 flow no problem!


Is this a CX5/CX6-DX hardware issue?&nbsp;
or Is it a DPDK mlx5 pmd bugs?


Best Regards!
KANG
  
Slava Ovsiienko May 6, 2021, 10:55 a.m. UTC | #8
Hi, Kang

There are have some questions to clarify:
 - what Is packet packet rate (in packet-per-second)?

  *   what Is packet size?
  *   do you use the switchdev configuration (E-Switch)?
  *   could you try create all flows in group 1 (and have the first flow in group 0 forwarding all the traffic to group 1) ?

With best regards,
Slava

From: Arthas <kangzy1982@qq.com>
Sent: Thursday, May 6, 2021 11:00
To: Gregory Etelson <getelson@nvidia.com>; dev@dpdk.org
Cc: Matan Azrad <matan@nvidia.com>; Ori Kam <orika@nvidia.com>; Raslan Darawsheh <rasland@nvidia.com>; stable@dpdk.org; Slava Ovsiienko <viacheslavo@nvidia.com>; Shahaf Shuler <shahafs@nvidia.com>
Subject: [dpdk-dev] net/mlx5: mellanox cx5/cx6-dx increment "rx_phy_discard_packets" with DPDK rte_flow actions COUNT & DROP

Hareware:  CX5/CX6 DX + Intel(R) Xeon(R) Platinum 9242 CPU @ 2.30GHz
DPDK version: 19.11.8/20.11/21.05-rc1&2

testpmd with case:
testpmd> flow create 0 ingress pattern eth / ipv4 / udp dst is 53 / end actions count / drop / end
testpmd> flow create 0 ingress pattern eth / ipv4 / udp src is 53 / end actions count / drop / end
testpmd> flow create 0 ingress pattern eth / ipv4 / tcp / end actions count /drop end
testpmd> flow list 0
ID         Group   Prio        Attr        Rule
0           0              0              i--            ETH IPV4 UDP => COUNT DROP
1           0              0              i--            ETH IPV4 UDP => COUNT DROP
2           0              0              i--            ETH IPV4 UDP => COUNT DROP
or
testpmd> flow create 0 ingress pattern eth / ipv4 / udp dst is 53 / end actions count / rss / end
testpmd> flow create 0 ingress pattern eth / ipv4 / udp src is 53 / end actions count / rss / end
testpmd> flow create 0 ingress pattern eth / ipv4 / udp / end actions count / rss / end
testpmd> flow list 0
ID         Group   Prio        Attr        Rule
0           0              0              i--            ETH IPV4 UDP => COUNT RSS
1           0              0              i--            ETH IPV4 UDP => COUNT RSS
2           0              0              i--            ETH IPV4 UDP => COUNT RSS
testpmd>

as soon as NIC create more than 1 flow ,  CX5/CX6-dx NIC will increment 'rx_phy_discard_packets'.
only 1 flow no problem!

Is this a CX5/CX6-DX hardware issue?
or Is it a DPDK mlx5 pmd bugs?

Best Regards!
KANG
  

Patch

diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 15ed5ec7a2..a7ceafe221 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -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 *
@@ -5910,22 +5911,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;
@@ -6120,12 +6113,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) {
@@ -6189,7 +6181,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;
@@ -8104,6 +8096,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
  */
@@ -8134,13 +8148,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,
@@ -8226,6 +8240,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);
@@ -8839,6 +8854,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 56908ae08b..cc3e79d088 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. */
@@ -911,10 +922,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);
@@ -923,23 +934,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 *
@@ -1223,11 +1226,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;
 
@@ -1243,7 +1245,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
@@ -1552,4 +1554,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,
 		       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_ */
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index d810466242..1caca61577 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -6315,33 +6315,34 @@  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;
 	bool def_policy = false;
 
 	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;
@@ -11191,13 +11192,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)
@@ -11212,15 +11214,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)
@@ -11230,7 +11238,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