patches for DPDK stable branches
 help / color / mirror / Atom feed
From: Dariusz Sosnowski <dsosnowski@nvidia.com>
To: Matan Azrad <matan@nvidia.com>,
	Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Cc: <dev@dpdk.org>, <stable@dpdk.org>, Ori Kam <orika@nvidia.com>
Subject: [PATCH 1/2] net/mlx5: fix egress group translation in HWS
Date: Sat, 25 Feb 2023 20:18:09 +0000	[thread overview]
Message-ID: <20230225201810.10838-2-dsosnowski@nvidia.com> (raw)
In-Reply-To: <20230225201810.10838-1-dsosnowski@nvidia.com>

With HW Steering enabled creating egress template tables and
egress flow rules on E-Switch setups is allowed.
To enable it, PMD creates a set of default egress flow rules
responsible for:

- Storing representor ID (vport tag is used) in HW register.
  This is used for traffic source identification.
- Copying software metadata to proper HW register to allow
  preserving metadata across domains.

Structure of these flow rules and whether they are inserted
depend on the device configuration.
There are the following cases:

1. repr_matching=1 and dv_xmeta_en=4
   - An egress flow rule in group 0 is created for each Tx queue;
   - Flow rule matching SQ number - fills unused REG_C_0 bits
     with vport tag, copies REG_A to REG_C_1 and jumps to group 1.
2. repr_matching=1 and dv_xmeta_en=0
   - An egress flow rule in group 0 is created for each Tx queue;
   - Flow rule matching SQ number - fills unused REG_C_0 bits
     with vport tag and jumps to group 1.
3. repr_matching=0 and dv_xmeta_en=4
   - A single egress flow rule in group 0 is created;
   - Flow rule matches all E-Switch manager TX traffic,
     copies REG_A to REG_C and jumps to group 1.
4. repr_matching=0 and dv_xmeta_en=0 - no default flow rules are added.

When default egress flow rules are required, they are inserted in
group 0 and this group is reserved for PMD purposes.
User created template tables must be created in higher groups.
As a result, on template table creation PMD is translating
the provided group (incrementing it in that case).

Before this patch, a condition used to check if translation of egress
flow group is needed was incorrect. It did not allow translation
if both representor matching AND extended metadata mode were enabled.

This patch fixes this condition - translation is allowed if and only if
representor matching OR extended metadata mode is enabled.

Fixes: 483181f7b6dd ("net/mlx5: support device control of representor matching")
Cc: stable@dpdk.org

Signed-off-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
---
 drivers/net/mlx5/mlx5_flow_hw.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index a9c7045a3e..d3d86fe24d 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -3260,14 +3260,18 @@ flow_hw_translate_group(struct rte_eth_dev *dev,
 						  "group index not supported");
 		*table_group = group + 1;
 	} else if (config->dv_esw_en &&
-		   !(config->repr_matching && config->dv_xmeta_en == MLX5_XMETA_MODE_META32_HWS) &&
+		   (config->repr_matching || config->dv_xmeta_en == MLX5_XMETA_MODE_META32_HWS) &&
 		   cfg->external &&
 		   flow_attr->egress) {
 		/*
-		 * On E-Switch setups, egress group translation is not done if and only if
-		 * representor matching is disabled and legacy metadata mode is selected.
-		 * In all other cases, egree group 0 is reserved for representor tagging flows
-		 * and metadata copy flows.
+		 * On E-Switch setups, default egress flow rules are inserted to allow
+		 * representor matching and/or preserving metadata across steering domains.
+		 * These flow rules are inserted in group 0 and this group is reserved by PMD
+		 * for these purposes.
+		 *
+		 * As a result, if representor matching or extended metadata mode is enabled,
+		 * group provided by the user must be incremented to avoid inserting flow rules
+		 * in group 0.
 		 */
 		if (group > MLX5_HW_MAX_EGRESS_GROUP)
 			return rte_flow_error_set(error, EINVAL,
-- 
2.25.1


  reply	other threads:[~2023-02-25 20:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-25 20:18 [PATCH 0/2] net/mlx5: fix representor matching Dariusz Sosnowski
2023-02-25 20:18 ` Dariusz Sosnowski [this message]
2023-03-08  3:04   ` [PATCH 1/2] net/mlx5: fix egress group translation in HWS Suanming Mou
2023-02-25 20:18 ` [PATCH 2/2] net/mlx5: fix isolated mode when repr matching is disabled Dariusz Sosnowski
2023-03-08  3:04   ` Suanming Mou
2023-03-19 15:32 ` [PATCH 0/2] net/mlx5: fix representor matching Matan Azrad
2023-03-19 17:26 ` 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=20230225201810.10838-2-dsosnowski@nvidia.com \
    --to=dsosnowski@nvidia.com \
    --cc=dev@dpdk.org \
    --cc=matan@nvidia.com \
    --cc=orika@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).