[PATCH] net/mlx5: fix hairpin split with set VLAN VID action

[PATCH] net/mlx5: fix hairpin split with set VLAN VID action

[Dariusz Sosnowski]

Before this patch any flow rule which works on hairpin queues
and which has OF_SET_VLAN_VID action was split into 2 flow rules:

- one subflow for Rx,
- one subflow for Tx.

OF_SET_VLAN_VID action was always placed in the Tx subflow.

Assuming a flow rule which matches VLAN traffic and has both
OF_SET_VLAN_VID action, and MODIFY_FIELD action on VLAN VID,
but no OF_PUSH_VLAN action, the following happened:

- MODIFY_FIELD action was placed in Rx subflow,
- OF_SET_VLAN_VID action was placed in Tx subflow,
- OF_SET_VLAN_VID action is internally compiled to a header modify
  command.

This caused the following issues:

1. Since OF_SET_VLAN_VID was placed in Tx subflow, 2 header modify
   actions were allocated. One for Rx and one for Tx.
2. If OF_SET_VLAN_VID action was placed before MODIFY_FIELD on VLAN VID,
   the flow rule executed header modifications in reverse order.
   MODIFY_FIELD actions were executed first in the Rx subflow and
   OF_SET_VLAN_VID was executed second in Tx subflow.

This patch fixes this behavior by not splitting hairpin flow rules
if OF_SET_VLAN_VID action is used without OF_PUSH_VLAN.
On top of that, if flow rule is split, the OF_SET_VLAN_VID action
is not moved to Tx subflow (for flow rules mentioned above).

Fixes: 210008309b45 ("net/mlx5: fix VLAN push action on hairpin queue")
Cc: stable@dpdk.org

Signed-off-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
---
 drivers/net/mlx5/mlx5_flow.c | 24 ++++++++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 65af1b4dd5..ea88882b88 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -4591,6 +4591,7 @@ flow_check_hairpin_split(struct rte_eth_dev *dev,
 	int queue_action = 0;
 	int action_n = 0;
 	int split = 0;
+	int push_vlan = 0;
 	const struct rte_flow_action_queue *queue;
 	const struct rte_flow_action_rss *rss;
 	const struct rte_flow_action_raw_encap *raw_encap;
@@ -4599,6 +4600,8 @@ flow_check_hairpin_split(struct rte_eth_dev *dev,
 	if (!attr->ingress)
 		return 0;
 	for (; actions->type != RTE_FLOW_ACTION_TYPE_END; actions++) {
+		if (actions->type == RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN)
+			push_vlan = 1;
 		switch (actions->type) {
 		case RTE_FLOW_ACTION_TYPE_QUEUE:
 			queue = actions->conf;
@@ -4623,11 +4626,15 @@ flow_check_hairpin_split(struct rte_eth_dev *dev,
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN:
-		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
 		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP:
 			split++;
 			action_n++;
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
+			if (push_vlan)
+				split++;
+			action_n++;
+			break;
 		case RTE_FLOW_ACTION_TYPE_RAW_ENCAP:
 			raw_encap = actions->conf;
 			if (raw_encap->size > MLX5_ENCAPSULATION_DECISION_SIZE)
@@ -5088,19 +5095,32 @@ flow_hairpin_split(struct rte_eth_dev *dev,
 	struct mlx5_rte_flow_item_tag *tag_item;
 	struct rte_flow_item *item;
 	char *addr;
+	int push_vlan = 0;
 	int encap = 0;
 
 	for (; actions->type != RTE_FLOW_ACTION_TYPE_END; actions++) {
+		if (actions->type == RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN)
+			push_vlan = 1;
 		switch (actions->type) {
 		case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
 		case RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN:
-		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
 		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP:
 			rte_memcpy(actions_tx, actions,
 			       sizeof(struct rte_flow_action));
 			actions_tx++;
 			break;
+		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
+			if (push_vlan) {
+				rte_memcpy(actions_tx, actions,
+					   sizeof(struct rte_flow_action));
+				actions_tx++;
+			} else {
+				rte_memcpy(actions_rx, actions,
+					   sizeof(struct rte_flow_action));
+				actions_rx++;
+			}
+			break;
 		case RTE_FLOW_ACTION_TYPE_COUNT:
 			if (encap) {
 				rte_memcpy(actions_tx, actions,
-- 
2.25.1

RE: [PATCH] net/mlx5: fix hairpin split with set VLAN VID action

[Raslan Darawsheh]

Hi,

> -----Original Message-----
> From: Dariusz Sosnowski <dsosnowski@nvidia.com>
> Sent: Monday, November 7, 2022 12:29 PM
> To: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> <viacheslavo@nvidia.com>
> Cc: dev@dpdk.org; Raslan Darawsheh <rasland@nvidia.com>;
> stable@dpdk.org
> Subject: [PATCH] net/mlx5: fix hairpin split with set VLAN VID action
> 
> Before this patch any flow rule which works on hairpin queues and which has
> OF_SET_VLAN_VID action was split into 2 flow rules:
> 
> - one subflow for Rx,
> - one subflow for Tx.
> 
> OF_SET_VLAN_VID action was always placed in the Tx subflow.
> 
> Assuming a flow rule which matches VLAN traffic and has both
> OF_SET_VLAN_VID action, and MODIFY_FIELD action on VLAN VID, but no
> OF_PUSH_VLAN action, the following happened:
> 
> - MODIFY_FIELD action was placed in Rx subflow,
> - OF_SET_VLAN_VID action was placed in Tx subflow,
> - OF_SET_VLAN_VID action is internally compiled to a header modify
>   command.
> 
> This caused the following issues:
> 
> 1. Since OF_SET_VLAN_VID was placed in Tx subflow, 2 header modify
>    actions were allocated. One for Rx and one for Tx.
> 2. If OF_SET_VLAN_VID action was placed before MODIFY_FIELD on VLAN
> VID,
>    the flow rule executed header modifications in reverse order.
>    MODIFY_FIELD actions were executed first in the Rx subflow and
>    OF_SET_VLAN_VID was executed second in Tx subflow.
> 
> This patch fixes this behavior by not splitting hairpin flow rules if
> OF_SET_VLAN_VID action is used without OF_PUSH_VLAN.
> On top of that, if flow rule is split, the OF_SET_VLAN_VID action is not moved
> to Tx subflow (for flow rules mentioned above).
> 
> Fixes: 210008309b45 ("net/mlx5: fix VLAN push action on hairpin queue")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
> Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>

Patch applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh