From: Dariusz Sosnowski <dsosnowski@nvidia.com>
To: Matan Azrad <matan@nvidia.com>,
Viacheslav 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
Date: Mon, 7 Nov 2022 10:28:52 +0000 [thread overview]
Message-ID: <20221107102852.365631-1-dsosnowski@nvidia.com> (raw)
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
next reply other threads:[~2022-11-07 10:29 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-07 10:28 Dariusz Sosnowski [this message]
2022-11-08 9:02 ` Raslan Darawsheh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221107102852.365631-1-dsosnowski@nvidia.com \
--to=dsosnowski@nvidia.com \
--cc=dev@dpdk.org \
--cc=matan@nvidia.com \
--cc=rasland@nvidia.com \
--cc=stable@dpdk.org \
--cc=viacheslavo@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).