DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bing Zhao <bingz@mellanox.com>
To: orika@mellanox.com, viacheslavo@mellanox.com
Cc: rasland@mellanox.com, matan@mellanox.com, dev@dpdk.org
Subject: [dpdk-dev] [PATCH] net/mlx5: fix the compatibility with MISC4
Date: Mon, 20 Jul 2020 17:03:42 +0800	[thread overview]
Message-ID: <1595235822-114874-1-git-send-email-bingz@mellanox.com> (raw)

When eCPRI offloading is introduced, the support for misc parameters
4 of flow table entry (FTE) match set is needed. The structure of
"mlx5_ifc_fte_match_param_bits" is extended with
"mlx5_ifc_fte_match_set_misc4_bits" at the end of it. The total size
of the FTE match set will be changed into 384 bytes from 320 bytes.
Low level user space driver (rdma-core) will have the validation of
the length of FTE match set. In the old release that no MISC4
supported in the rdma-core, the validation will fail, and this will
break the backward compatibility, even if the MISC4 is not used in
most cases.
In order to make new mlx5 PMD work well with old rdma-core, the
length adjustment needs to be done. When creating a flow, the lengths
of the matcher and value are both set to 320 without MISC4. There is
no need to change the structure definition, all bytes of the MISC4
will be discarded if it is not needed. Or else, like in eCPRI
matching, the lengths will be adjusted to 384 for matcher creation
and value matching.

Fixes: afa8556c873c ("net/mlx5: add flow translation of eCPRI header")

Signed-off-by: Bing Zhao <bingz@mellanox.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
---
 drivers/net/mlx5/mlx5_flow_dv.c | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index ee66a44..778a766 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -5765,7 +5765,15 @@ struct field_modify_info modify_tcp[] = {
 	dev_flow = &((struct mlx5_flow *)priv->inter_flows)[priv->flow_idx++];
 	dev_flow->handle = dev_handle;
 	dev_flow->handle_idx = handle_idx;
-	dev_flow->dv.value.size = MLX5_ST_SZ_BYTES(fte_match_param);
+	/*
+	 * In some old rdma-core releases, before continuing, a check of the
+	 * length of matching parameter will be done at first. It needs to use
+	 * the length without misc4 param. If the flow has misc4 support, then
+	 * the length needs to be adjusted accordingly. Each param member is
+	 * aligned with a 64B boundary naturally.
+	 */
+	dev_flow->dv.value.size = MLX5_ST_SZ_BYTES(fte_match_param) -
+				  MLX5_ST_SZ_BYTES(fte_match_set_misc4);
 	/*
 	 * The matching value needs to be cleared to 0 before using. In the
 	 * past, it will be automatically cleared when using rte_*alloc
@@ -7986,7 +7994,8 @@ struct field_modify_info modify_tcp[] = {
 	uint64_t priority = attr->priority;
 	struct mlx5_flow_dv_matcher matcher = {
 		.mask = {
-			.size = sizeof(matcher.mask.buf),
+			.size = sizeof(matcher.mask.buf) -
+				MLX5_ST_SZ_BYTES(fte_match_set_misc4),
 		},
 	};
 	int actions_n = 0;
@@ -8678,6 +8687,10 @@ struct field_modify_info modify_tcp[] = {
 						NULL,
 						"cannot create eCPRI parser");
 			}
+			/* Adjust the length matcher and device flow value. */
+			matcher.mask.size = MLX5_ST_SZ_BYTES(fte_match_param);
+			dev_flow->dv.value.size =
+					MLX5_ST_SZ_BYTES(fte_match_param);
 			flow_dv_translate_item_ecpri(dev, match_mask,
 						     match_value, items);
 			/* No other protocol should follow eCPRI layer. */
-- 
1.8.3.1


             reply	other threads:[~2020-07-20  9:03 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-20  9:03 Bing Zhao [this message]
2020-07-20 12:14 ` 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=1595235822-114874-1-git-send-email-bingz@mellanox.com \
    --to=bingz@mellanox.com \
    --cc=dev@dpdk.org \
    --cc=matan@mellanox.com \
    --cc=orika@mellanox.com \
    --cc=rasland@mellanox.com \
    --cc=viacheslavo@mellanox.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).