[dpdk-dev] [PATCH] net/mlx5: fix meter profile validation

[dpdk-dev] [PATCH] net/mlx5: fix meter profile validation

[Bing Zhao]

After the support for yellow color and RFC2698 & RFC4115 were added,
the profile validation adjustment was missed. With this fix, the
validation is like below:
  1. Legacy metering only supports RFC2697 without EBS.
  2. ASO metering can support all the three profiles.
  3. For backward compatibility, none EBS with RFC2697 profile is
     still supported and the checking is done in the meter
     creation stage.

In the meanwhile, some checking which was done in the parameters
calculation stage is moved in the validation in order to skip the
useless checking.

Fixes: 33a7493c8df8 ("net/mlx5: support meter for trTCM profiles")

Signed-off-by: Bing Zhao <bingz@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
---
 drivers/common/mlx5/mlx5_prm.h     |   7 +-
 drivers/net/mlx5/mlx5_flow_meter.c | 139 ++++++++++++++++++-----------
 2 files changed, 88 insertions(+), 58 deletions(-)

diff --git a/drivers/common/mlx5/mlx5_prm.h b/drivers/common/mlx5/mlx5_prm.h
index 5b73a193ee..fdb20f5d49 100644
--- a/drivers/common/mlx5/mlx5_prm.h
+++ b/drivers/common/mlx5/mlx5_prm.h
@@ -3849,10 +3849,9 @@ enum {
 	MLX5_FLOW_COLOR_UNDEFINED,
 };
 
-/* Maximum value of srTCM metering parameters. */
-#define MLX5_SRTCM_CBS_MAX (0xFF * (1ULL << 0x1F))
-#define MLX5_SRTCM_CIR_MAX (8 * (1ULL << 30) * 0xFF)
-#define MLX5_SRTCM_EBS_MAX 0
+/* Maximum value of srTCM & trTCM metering parameters. */
+#define MLX5_SRTCM_XBS_MAX (0xFF * (1ULL << 0x1F))
+#define MLX5_SRTCM_XIR_MAX (8 * (1ULL << 30) * 0xFF)
 
 /* The bits meter color use. */
 #define MLX5_MTR_COLOR_BITS 8
diff --git a/drivers/net/mlx5/mlx5_flow_meter.c b/drivers/net/mlx5/mlx5_flow_meter.c
index 2d91a6fcf0..0f51710907 100644
--- a/drivers/net/mlx5/mlx5_flow_meter.c
+++ b/drivers/net/mlx5/mlx5_flow_meter.c
@@ -130,6 +130,11 @@ mlx5_flow_meter_profile_validate(struct rte_eth_dev *dev,
 {
 	struct mlx5_priv *priv = dev->data->dev_private;
 	struct mlx5_flow_meter_profile *fmp;
+	uint32_t ls_factor;
+	int ret;
+	uint64_t cir, cbs;
+	uint64_t eir, ebs;
+	uint64_t pir, pbs;
 
 	/* Profile must not be NULL. */
 	if (profile == NULL)
@@ -148,50 +153,83 @@ mlx5_flow_meter_profile_validate(struct rte_eth_dev *dev,
 					  RTE_MTR_ERROR_TYPE_METER_PROFILE_ID,
 					  NULL,
 					  "Meter profile already exists.");
-	if (profile->alg == RTE_MTR_SRTCM_RFC2697) {
-		if (priv->config.hca_attr.qos.flow_meter_old) {
-			/* Verify support for flow meter parameters. */
-			if (priv->sh->meter_aso_en && profile->packet_mode) {
-				if (profile->srtcm_rfc2697.cir > 0 &&
-					(profile->srtcm_rfc2697.cir <<
-					MLX5_MTRS_PPS_MAP_BPS_SHIFT)
-					<= MLX5_SRTCM_CIR_MAX &&
-					profile->srtcm_rfc2697.cbs > 0 &&
-					(profile->srtcm_rfc2697.cbs <<
-					MLX5_MTRS_PPS_MAP_BPS_SHIFT)
-					<= MLX5_SRTCM_CBS_MAX &&
-					(profile->srtcm_rfc2697.ebs <<
-					MLX5_MTRS_PPS_MAP_BPS_SHIFT)
-					<= MLX5_SRTCM_EBS_MAX)
-					return 0;
-				return -rte_mtr_error_set
-					     (error, ENOTSUP,
-					      RTE_MTR_ERROR_TYPE_MTR_PARAMS,
-					      NULL,
-					      profile->srtcm_rfc2697.ebs ?
-					      "Metering value ebs must be 0." :
-					      "Invalid metering parameters.");
-			}
-			if (profile->srtcm_rfc2697.cir > 0 &&
-				profile->srtcm_rfc2697.cir <=
-						MLX5_SRTCM_CIR_MAX &&
-				profile->srtcm_rfc2697.cbs > 0 &&
-				profile->srtcm_rfc2697.cbs <=
-						MLX5_SRTCM_CBS_MAX &&
-				profile->srtcm_rfc2697.ebs <=
-						MLX5_SRTCM_EBS_MAX)
-				return 0;
+	if (!priv->sh->meter_aso_en) {
+		/* Old version is even not supported. */
+		if (!priv->config.hca_attr.qos.flow_meter_old)
 			return -rte_mtr_error_set(error, ENOTSUP,
-					RTE_MTR_ERROR_TYPE_MTR_PARAMS,
-					NULL,
-					profile->srtcm_rfc2697.ebs ?
-					"Metering value ebs must be 0." :
-					"Invalid metering parameters.");
+				RTE_MTR_ERROR_TYPE_METER_PROFILE,
+				NULL, "Metering is not supported.");
+		/* Old FW metering only supports srTCM. */
+		if (profile->alg != RTE_MTR_SRTCM_RFC2697) {
+			return -rte_mtr_error_set(error, ENOTSUP,
+				RTE_MTR_ERROR_TYPE_METER_PROFILE,
+				NULL, "Metering algorithm is not supported.");
+		} else if (profile->srtcm_rfc2697.ebs) {
+			/* EBS is not supported for old metering. */
+			return -rte_mtr_error_set(error, ENOTSUP,
+				RTE_MTR_ERROR_TYPE_METER_PROFILE,
+				NULL, "EBS is not supported.");
 		}
+		if (profile->packet_mode)
+			return -rte_mtr_error_set(error, ENOTSUP,
+				RTE_MTR_ERROR_TYPE_METER_PROFILE, NULL,
+				"Metering algorithm packet mode is not supported.");
 	}
-	return -rte_mtr_error_set(error, ENOTSUP,
-				  RTE_MTR_ERROR_TYPE_METER_PROFILE,
-				  NULL, "Metering algorithm not supported.");
+	ls_factor = profile->packet_mode ? MLX5_MTRS_PPS_MAP_BPS_SHIFT : 0;
+	switch (profile->alg) {
+	case RTE_MTR_SRTCM_RFC2697:
+		cir = profile->srtcm_rfc2697.cir << ls_factor;
+		cbs = profile->srtcm_rfc2697.cbs << ls_factor;
+		ebs = profile->srtcm_rfc2697.ebs << ls_factor;
+		/* EBS could be zero for old metering. */
+		if (cir > 0 && cir <= MLX5_SRTCM_XIR_MAX &&
+		    cbs > 0 && cbs <= MLX5_SRTCM_XBS_MAX &&
+		    ebs <= MLX5_SRTCM_XBS_MAX) {
+			ret = 0;
+		} else {
+			ret = -rte_mtr_error_set(error, ENOTSUP,
+					RTE_MTR_ERROR_TYPE_MTR_PARAMS, NULL,
+					"Profile values out of range.");
+		}
+		break;
+	case RTE_MTR_TRTCM_RFC2698:
+		cir = profile->trtcm_rfc2698.cir << ls_factor;
+		cbs = profile->trtcm_rfc2698.cbs << ls_factor;
+		pir = profile->trtcm_rfc2698.pir << ls_factor;
+		pbs = profile->trtcm_rfc2698.pbs << ls_factor;
+		if (cir > 0 && cir <= MLX5_SRTCM_XIR_MAX &&
+		    cbs > 0 && cbs <= MLX5_SRTCM_XBS_MAX &&
+		    pir >= cir && pir <= (MLX5_SRTCM_XIR_MAX * 2) &&
+		    pbs >= cbs && pbs <= (MLX5_SRTCM_XBS_MAX * 2)) {
+			ret = 0;
+		} else {
+			ret = -rte_mtr_error_set(error, ENOTSUP,
+					RTE_MTR_ERROR_TYPE_MTR_PARAMS, NULL,
+					"Profile values out of range.");
+		}
+		break;
+	case RTE_MTR_TRTCM_RFC4115:
+		cir = profile->trtcm_rfc4115.cir << ls_factor;
+		cbs = profile->trtcm_rfc4115.cbs << ls_factor;
+		eir = profile->trtcm_rfc4115.eir << ls_factor;
+		ebs = profile->trtcm_rfc4115.ebs << ls_factor;
+		if (cir > 0 && cir <= MLX5_SRTCM_XIR_MAX &&
+		    cbs > 0 && cbs <= MLX5_SRTCM_XBS_MAX &&
+		    eir <= MLX5_SRTCM_XIR_MAX && ebs <= MLX5_SRTCM_XBS_MAX) {
+			ret = 0;
+		} else {
+			ret = -rte_mtr_error_set(error, ENOTSUP,
+					RTE_MTR_ERROR_TYPE_MTR_PARAMS, NULL,
+					"Profile values out of range.");
+		}
+		break;
+	default:
+		ret = -rte_mtr_error_set(error, ENOTSUP,
+					 RTE_MTR_ERROR_TYPE_MTR_PARAMS, NULL,
+					 "Unknown metering algorithm.");
+		break;
+	}
+	return ret;
 }
 
 /*
@@ -270,7 +308,7 @@ mlx5_flow_meter_xbs_man_exp_calc(uint64_t xbs, uint8_t *man, uint8_t *exp)
  */
 static int
 mlx5_flow_meter_param_fill(struct mlx5_flow_meter_profile *fmp,
-			struct mlx5_priv *priv, struct rte_mtr_error *error)
+			   struct rte_mtr_error *error)
 {
 	struct mlx5_flow_meter_srtcm_rfc2697_prm *srtcm = &fmp->srtcm_prm;
 	uint8_t man, exp;
@@ -278,17 +316,6 @@ mlx5_flow_meter_param_fill(struct mlx5_flow_meter_profile *fmp,
 	uint32_t eir_exp, eir_man, ebs_exp, ebs_man;
 	uint64_t cir, cbs, eir, ebs;
 
-	if (!priv->sh->meter_aso_en) {
-		/* Legacy FW metering will only support srTCM. */
-		if (fmp->profile.alg != RTE_MTR_SRTCM_RFC2697)
-			return -rte_mtr_error_set(error, ENOTSUP,
-				RTE_MTR_ERROR_TYPE_METER_PROFILE,
-				NULL, "Metering algorithm is not supported.");
-		if (fmp->profile.packet_mode)
-			return -rte_mtr_error_set(error, ENOTSUP,
-				RTE_MTR_ERROR_TYPE_METER_PROFILE, NULL,
-				"Metering algorithm packet mode is not supported.");
-	}
 	switch (fmp->profile.alg) {
 	case RTE_MTR_SRTCM_RFC2697:
 		cir = fmp->profile.srtcm_rfc2697.cir;
@@ -469,7 +496,7 @@ mlx5_flow_meter_profile_add(struct rte_eth_dev *dev,
 	fmp->id = meter_profile_id;
 	fmp->profile = *profile;
 	/* Fill the flow meter parameters for the PRM. */
-	ret = mlx5_flow_meter_param_fill(fmp, priv, error);
+	ret = mlx5_flow_meter_param_fill(fmp, error);
 	if (ret)
 		goto error;
 	data.ptr = fmp;
@@ -1210,6 +1237,10 @@ mlx5_flow_meter_create(struct rte_eth_dev *dev, uint32_t meter_id,
 		aso_mtr = mlx5_aso_meter_by_idx(priv, mtr_idx);
 		fm = &aso_mtr->fm;
 	} else {
+		if (fmp->y_support)
+			return -rte_mtr_error_set(error, ENOMEM,
+				RTE_MTR_ERROR_TYPE_UNSPECIFIED, NULL,
+				"Unsupported profile with yellow.");
 		legacy_fm = mlx5_ipool_zmalloc
 				(priv->sh->ipool[MLX5_IPOOL_MTR], &mtr_idx);
 		if (legacy_fm == NULL)
-- 
2.27.0

[dpdk-dev] [PATCH] net/mlx5: fix the EIR calculation

[Bing Zhao]

Before the yellow color policy was supported, the only supported
profile of metering is RFC2697 and EIR is not part of the profile.
When creating a meter with this profile, the EIR part was always
zero.

After the yellow color policy supported and RFC2698 & 4115 support
was introduced, EIR is relevant and should be calculated. Usually
the EIR could not be zero and the formula for calculating CIR
mantissa & exponent could be reused.

The EIR could be 0 and then only green and red colors will be
supported from the specification. Both the mantissa and exponent
parts should be set to 0. Currently, the formula wrongly sets
non-zero values for the EIR=0 case.

Setting the mantissa and the exponent parts to zeros when EIR is 0
will solve the issue.

Fixes: 33a7493c8df8 ("net/mlx5: support meter for trTCM profiles")

Signed-off-by: Bing Zhao <bingz@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
---
 drivers/net/mlx5/mlx5_flow_meter.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow_meter.c b/drivers/net/mlx5/mlx5_flow_meter.c
index 0f51710907..a24bd9c7ae 100644
--- a/drivers/net/mlx5/mlx5_flow_meter.c
+++ b/drivers/net/mlx5/mlx5_flow_meter.c
@@ -245,17 +245,23 @@ mlx5_flow_meter_profile_validate(struct rte_eth_dev *dev,
 static inline void
 mlx5_flow_meter_xir_man_exp_calc(int64_t xir, uint8_t *man, uint8_t *exp)
 {
-	int64_t _cir;
+	int64_t _xir;
 	int64_t delta = INT64_MAX;
 	uint8_t _man = 0;
 	uint8_t _exp = 0;
 	uint64_t m, e;
 
+	/* Special case xir == 0 ? both exp and matissa are 0. */
+	if (xir == 0) {
+		*man = 0;
+		*exp = 0;
+		return;
+	}
 	for (m = 0; m <= 0xFF; m++) { /* man width 8 bit */
 		for (e = 0; e <= 0x1F; e++) { /* exp width 5bit */
-			_cir = (1000000000ULL * m) >> e;
-			if (llabs(xir - _cir) <= delta) {
-				delta = llabs(xir - _cir);
+			_xir = (1000000000ULL * m) >> e;
+			if (llabs(xir - _xir) <= delta) {
+				delta = llabs(xir - _xir);
 				_man = m;
 				_exp = e;
 			}
-- 
2.27.0

[dpdk-dev] [PATCH] net/mlx5: fix the green color policy RSS queues overwritten

[Bing Zhao]

Both green policy and yellow policy could support RSS actions
simultaneous, the Rx queues configuration may be different between
them while the other fields should be the same.

When the only green color policy was supported in the past, the
queues copied and saved in the temporary workspace were used. Since
the yellow support was added, the queues stored in the thread
workspace would be overwritten by the yellow color policy. The flow
rule created using a meter with such a policy would have the same
RSS distribution for both green and yellow packets.

By using the meter action containers RSS information instead of the
workspace RSS, this overwritten can be prevented.

Fixes: b38a12272b3a ("net/mlx5: split meter color policy handling")

Signed-off-by: Bing Zhao <bingz@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
---
 drivers/net/mlx5/mlx5_flow.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index f7f16883cd..0689e6d45d 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -4710,7 +4710,7 @@ get_meter_sub_policy(struct rte_eth_dev *dev,
 			uint8_t fate = final_policy->act_cnt[i].fate_action;
 
 			if (fate == MLX5_FLOW_FATE_SHARED_RSS) {
-				const void *rss_act =
+				const struct rte_flow_action_rss *rss_act =
 					final_policy->act_cnt[i].rss->conf;
 				struct rte_flow_action rss_actions[2] = {
 					[0] = {
@@ -4746,6 +4746,9 @@ get_meter_sub_policy(struct rte_eth_dev *dev,
 				rss_desc_v[i].tunnel =
 						!!(dev_flow.handle->layers &
 						   MLX5_FLOW_LAYER_TUNNEL);
+				/* Use the RSS queues in the containers. */
+				rss_desc_v[i].queue =
+					(uint16_t *)(uintptr_t)rss_act->queue;
 				rss_desc[i] = &rss_desc_v[i];
 			} else if (fate == MLX5_FLOW_FATE_QUEUE) {
 				/* This is queue action. */
-- 
2.27.0

[dpdk-dev] [PATCH] net/mlx5: fix the meter hierarchy validation with yellow

[Bing Zhao]

In mlx5 PMD, the meter hierarchy only supports the green color. It
means that a meter action can only be in the green action list. In
the meanwhile, the yellow action list should be empty now. Any
action for the yellow color policy will be considered invalid if
the green color policy is a hierarchy.

Also, the error message printing of meter hierarchy validation is
fixed by removing an incorrect checking.

Fixes: 4b7bf3ffb473 ("net/mlx5: support yellow in meter policy validation")
Fixes: a3b7af90baba ("net/mlx5: validate meter action in policy")
Cc: shunh@nvidia.com

Signed-off-by: Bing Zhao <bingz@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
---
 drivers/net/mlx5/mlx5_flow_dv.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 837450722a..d5669e209d 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -17691,9 +17691,14 @@ flow_dv_validate_mtr_policy_acts(struct rte_eth_dev *dev,
 					return -rte_mtr_error_set(error,
 						ENOTSUP,
 						RTE_MTR_ERROR_TYPE_METER_POLICY,
-						NULL, flow_err.message ?
-						flow_err.message :
-				  "Meter hierarchy only supports GREEN color.");
+						NULL,
+						"Meter hierarchy only supports GREEN color.");
+				if (*policy_mode != MLX5_MTR_POLICY_MODE_OG)
+					return -rte_mtr_error_set(error,
+						ENOTSUP,
+						RTE_MTR_ERROR_TYPE_METER_POLICY,
+						NULL,
+						"No yellow policy should be provided in meter hierarchy.");
 				mtr = act->conf;
 				ret = flow_dv_validate_policy_mtr_hierarchy(dev,
 							mtr->mtr_id,
-- 
2.27.0

Re: [dpdk-dev] [PATCH] net/mlx5: fix meter profile validation

[Raslan Darawsheh]

Hi,

> -----Original Message-----
> From: Bing Zhao <bingz@nvidia.com>
> Sent: Thursday, July 29, 2021 7:04 PM
> To: Slava Ovsiienko <viacheslavo@nvidia.com>; Matan Azrad
> <matan@nvidia.com>
> Cc: dev@dpdk.org; Ori Kam <orika@nvidia.com>; Raslan Darawsheh
> <rasland@nvidia.com>; NBU-Contact-Thomas Monjalon
> <thomas@monjalon.net>
> Subject: [PATCH] net/mlx5: fix meter profile validation
> 
> After the support for yellow color and RFC2698 & RFC4115 were added, the
> profile validation adjustment was missed. With this fix, the validation is like
> below:
>   1. Legacy metering only supports RFC2697 without EBS.
>   2. ASO metering can support all three profiles.
>   3. For backward compatibility, none EBS with RFC2697 profile is
>      still supported and the checking is done in the meter
>      creation stage.
> 
> In the meanwhile, some checking which was done in the parameters
> calculation stage is moved in the validation in order to skip the useless
> checking.
> 
> Fixes: 33a7493c8df8 ("net/mlx5: support meter for trTCM profiles")
> 
> Signed-off-by: Bing Zhao <bingz@nvidia.com>
> Acked-by: Matan Azrad <matan@nvidia.com>
> ---

Patch applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh

Re: [dpdk-dev] [PATCH] net/mlx5: fix the EIR calculation

[Raslan Darawsheh]

Hi,

> -----Original Message-----
> From: Bing Zhao <bingz@nvidia.com>
> Sent: Thursday, July 29, 2021 7:04 PM
> To: Slava Ovsiienko <viacheslavo@nvidia.com>; Matan Azrad
> <matan@nvidia.com>
> Cc: dev@dpdk.org; Ori Kam <orika@nvidia.com>; Raslan Darawsheh
> <rasland@nvidia.com>; NBU-Contact-Thomas Monjalon
> <thomas@monjalon.net>
> Subject: [PATCH] net/mlx5: fix the EIR calculation
> 
> Before the yellow color policy was supported, the only supported profile of
> metering is RFC2697 and EIR is not part of the profile.
> When creating a meter with this profile, the EIR part was always zero.
> 
> After the yellow color policy supported and RFC2698 & 4115 support was
> introduced, EIR is relevant and should be calculated. Usually the EIR could not
> be zero and the formula for calculating CIR mantissa & exponent could be
> reused.
> 
> The EIR could be 0 and then only green and red colors will be supported from
> the specification. Both the mantissa and exponent parts should be set to 0.
> Currently, the formula wrongly sets non-zero values for the EIR=0 case.
> 
> Setting the mantissa and the exponent parts to zeros when EIR is 0 will solve
> the issue.
> 
> Fixes: 33a7493c8df8 ("net/mlx5: support meter for trTCM profiles")
> 
> Signed-off-by: Bing Zhao <bingz@nvidia.com>
> Acked-by: Matan Azrad <matan@nvidia.com>
> ---
>  drivers/net/mlx5/mlx5_flow_meter.c | 14 ++++++++++----
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 

Patch applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh

Re: [dpdk-dev] [PATCH] net/mlx5: fix the green color policy RSS queues overwritten

[Raslan Darawsheh]

Hi,

> -----Original Message-----
> From: Bing Zhao <bingz@nvidia.com>
> Sent: Thursday, July 29, 2021 7:04 PM
> To: Slava Ovsiienko <viacheslavo@nvidia.com>; Matan Azrad
> <matan@nvidia.com>
> Cc: dev@dpdk.org; Ori Kam <orika@nvidia.com>; Raslan Darawsheh
> <rasland@nvidia.com>; NBU-Contact-Thomas Monjalon
> <thomas@monjalon.net>
> Subject: [PATCH] net/mlx5: fix the green color policy RSS queues overwritten
> 
> Both green policy and yellow policy could support RSS actions simultaneous,
> the Rx queues configuration may be different between them while the other
> fields should be the same.
> 
> When the only green color policy was supported in the past, the queues
> copied and saved in the temporary workspace were used. Since the yellow
> support was added, the queues stored in the thread workspace would be
> overwritten by the yellow color policy. The flow rule created using a meter
> with such a policy would have the same RSS distribution for both green and
> yellow packets.
> 
> By using the meter action containers RSS information instead of the
> workspace RSS, this overwritten can be prevented.
> 
> Fixes: b38a12272b3a ("net/mlx5: split meter color policy handling")
> 
> Signed-off-by: Bing Zhao <bingz@nvidia.com>
> Acked-by: Matan Azrad <matan@nvidia.com>
> ---

Patch applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh

Re: [dpdk-dev] [PATCH] net/mlx5: fix the meter hierarchy validation with yellow

[Raslan Darawsheh]

Hi,

> -----Original Message-----
> From: Bing Zhao <bingz@nvidia.com>
> Sent: Thursday, July 29, 2021 7:04 PM
> To: Slava Ovsiienko <viacheslavo@nvidia.com>; Matan Azrad
> <matan@nvidia.com>
> Cc: dev@dpdk.org; Ori Kam <orika@nvidia.com>; Raslan Darawsheh
> <rasland@nvidia.com>; NBU-Contact-Thomas Monjalon
> <thomas@monjalon.net>; Shun Hao <shunh@nvidia.com>
> Subject: [PATCH] net/mlx5: fix the meter hierarchy validation with yellow
> 
> In mlx5 PMD, the meter hierarchy only supports the green color. It means
> that a meter action can only be in the green action list. In the meanwhile, the
> yellow action list should be empty now. Any action for the yellow color policy
> will be considered invalid if the green color policy is a hierarchy.
> 
> Also, the error message printing of meter hierarchy validation is fixed by
> removing an incorrect checking.
> 
> Fixes: 4b7bf3ffb473 ("net/mlx5: support yellow in meter policy validation")
> Fixes: a3b7af90baba ("net/mlx5: validate meter action in policy")
> Cc: shunh@nvidia.com
> 
> Signed-off-by: Bing Zhao <bingz@nvidia.com>
> Acked-by: Matan Azrad <matan@nvidia.com>
> ---
>  drivers/net/mlx5/mlx5_flow_dv.c | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 

Patch applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh