diff mbox series

net/mlx5: fix matching on eCPRI

Message ID 20210809142646.1918339-1-dkozlyuk@nvidia.com (mailing list archive)
State Accepted, archived
Delegated to: Raslan Darawsheh
Headers
Series net/mlx5: fix matching on eCPRI |

Checks

Context Check Description
ci/checkpatch warning coding style issues
ci/github-robot-build success github build: passed
ci/iol-broadcom-Performance success Performance Testing PASS
ci/iol-intel-Functional success Functional Testing PASS
ci/iol-aarch64-unit-testing success Testing PASS
ci/iol-broadcom-Functional success Functional Testing PASS
ci/iol-intel-Performance success Performance Testing PASS
ci/iol-aarch64-compile-testing success Testing PASS
ci/Intel-compilation success Compilation OK
ci/iol-abi-testing success Testing PASS
ci/iol-x86_64-compile-testing success Testing PASS
ci/iol-mellanox-Performance success Performance Testing PASS
ci/iol-x86_64-unit-testing fail Testing issues
ci/intel-Testing success Testing PASS

Commit Message

Dmitry Kozlyuk Aug. 9, 2021, 2:26 p.m. UTC 
  When an ETH or VLAN flow item directly preceding ECPRI (i. e. a pattern
for eCPRI over Ethernet) did not specify the eCPRI protocol, matches
were not restricted to eCPRI traffic. For example, "eth / ecpri / end"
pattern behaved as "eth / end". Implicitly add Ethernet type condition,
so that "eth / ecpri / end" behaves as "eth type is 0xAEFE / end".

Fixes: daa38a8924a0 ("net/mlx5: add flow translation of eCPRI header")
Cc: bingz@nvidia.com
Cc: stable@dpdk.org

Signed-off-by: Dmitry Kozlyuk <dkozlyuk@nvidia.com>
---
 drivers/net/mlx5/mlx5_flow_dv.c | 26 ++++++++++++++++++++++----
 1 file changed, 22 insertions(+), 4 deletions(-)

Comments

Matan Azrad Aug. 10, 2021, 6:22 a.m. UTC | #1 
From: Dmitry Kozlyuk
> When an ETH or VLAN flow item directly preceding ECPRI (i. e. a pattern for
> eCPRI over Ethernet) did not specify the eCPRI protocol, matches were not
> restricted to eCPRI traffic. For example, "eth / ecpri / end"
> pattern behaved as "eth / end". Implicitly add Ethernet type condition, so
> that "eth / ecpri / end" behaves as "eth type is 0xAEFE / end".
> 
> Fixes: daa38a8924a0 ("net/mlx5: add flow translation of eCPRI header")
> Cc: bingz@nvidia.com
> Cc: stable@dpdk.org
> 
> Signed-off-by: Dmitry Kozlyuk <dkozlyuk@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
Raslan Darawsheh Aug. 17, 2021, 9:49 a.m. UTC | #2 
Hi,

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Dmitry Kozlyuk
> Sent: Monday, August 9, 2021 5:27 PM
> To: dev@dpdk.org
> Cc: Bing Zhao <bingz@nvidia.com>; stable@dpdk.org; Matan Azrad
> <matan@nvidia.com>; Shahaf Shuler <shahafs@nvidia.com>; Slava
> Ovsiienko <viacheslavo@nvidia.com>
> Subject: [dpdk-dev] [PATCH] net/mlx5: fix matching on eCPRI
> 
> When an ETH or VLAN flow item directly preceding ECPRI (i. e. a pattern for
> eCPRI over Ethernet) did not specify the eCPRI protocol, matches were not
> restricted to eCPRI traffic. For example, "eth / ecpri / end"
> pattern behaved as "eth / end". Implicitly add Ethernet type condition, so
> that "eth / ecpri / end" behaves as "eth type is 0xAEFE / end".
> 
> Fixes: daa38a8924a0 ("net/mlx5: add flow translation of eCPRI header")
> Cc: bingz@nvidia.com
> Cc: stable@dpdk.org
> 
> Signed-off-by: Dmitry Kozlyuk <dkozlyuk@nvidia.com>

Patch applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh
diff mbox series

Patch

diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 31d857030f..5bb6d89a3f 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -9976,12 +9976,13 @@  flow_dv_translate_item_gtp_psc(void *matcher, void *key,
  *   Flow matcher value.
  * @param[in] item
  *   Flow pattern to translate.
- * @param[in] samples
- *   Sample IDs to be used in the matching.
+ * @param[in] last_item
+ *   Last item flags.
  */
 static void
 flow_dv_translate_item_ecpri(struct rte_eth_dev *dev, void *matcher,
-			     void *key, const struct rte_flow_item *item)
+			     void *key, const struct rte_flow_item *item,
+			     uint64_t last_item)
 {
 	struct mlx5_priv *priv = dev->data->dev_private;
 	const struct rte_flow_item_ecpri *ecpri_m = item->mask;
@@ -9994,6 +9995,22 @@  flow_dv_translate_item_ecpri(struct rte_eth_dev *dev, void *matcher,
 	void *dw_m;
 	void *dw_v;
 
+	/*
+	 * In case of eCPRI over Ethernet, if EtherType is not specified,
+	 * match on eCPRI EtherType implicitly.
+	 */
+	if (last_item & MLX5_FLOW_LAYER_OUTER_L2) {
+		void *hdrs_m, *hdrs_v, *l2m, *l2v;
+
+		hdrs_m = MLX5_ADDR_OF(fte_match_param, matcher, outer_headers);
+		hdrs_v = MLX5_ADDR_OF(fte_match_param, key, outer_headers);
+		l2m = MLX5_ADDR_OF(fte_match_set_lyr_2_4, hdrs_m, ethertype);
+		l2v = MLX5_ADDR_OF(fte_match_set_lyr_2_4, hdrs_v, ethertype);
+		if (*(uint16_t *)l2m == 0 && *(uint16_t *)l2v == 0) {
+			*(uint16_t *)l2m = UINT16_MAX;
+			*(uint16_t *)l2v = RTE_BE16(RTE_ETHER_TYPE_ECPRI);
+		}
+	}
 	if (!ecpri_v)
 		return;
 	if (!ecpri_m)
@@ -13474,7 +13491,8 @@  flow_dv_translate(struct rte_eth_dev *dev,
 						"cannot create eCPRI parser");
 			}
 			flow_dv_translate_item_ecpri(dev, match_mask,
-						     match_value, items);
+						     match_value, items,
+						     last_item);
 			/* No other protocol should follow eCPRI layer. */
 			last_item = MLX5_FLOW_LAYER_ECPRI;
 			break;