[dpdk-dev] [RFC 0/1] lib/librte_ethdev: Meter algorithms support packet per second.

[dpdk-dev] [RFC 0/1] lib/librte_ethdev: Meter algorithms support packet per second.

[Li Zhang]

Li Zhang (1):
  lib/librte_ethdev: add definitions for packet per second.

 lib/librte_ethdev/rte_mtr.h | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

-- 
2.27.0

[dpdk-dev] [PATCH] [RFC]: adds support PPS(packet per second) on meter

[Li Zhang]

Currently the flow Meter algorithms in rte_flow only supports bytes per second(BPS).
Such as Single Rate Three Color Marker (srTCM rfc2697)
This RFC adds the packet per second definition in Meter algorithms structure,
to support the rte_mtr APIs with type srTCM pps mode.
The below structure will be extended:
rte_mtr_algorithm
rte_mtr_meter_profile
Signed-off-by: Li Zhang <lizh@nvidia.com>
---
 lib/librte_ethdev/rte_mtr.h | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/lib/librte_ethdev/rte_mtr.h b/lib/librte_ethdev/rte_mtr.h
index 916a09c5c3..6413892aec 100644
--- a/lib/librte_ethdev/rte_mtr.h
+++ b/lib/librte_ethdev/rte_mtr.h
@@ -119,6 +119,9 @@ enum rte_mtr_algorithm {
 
 	/** Two Rate Three Color Marker (trTCM) - IETF RFC 4115. */
 	RTE_MTR_TRTCM_RFC4115,
+
+	/** Single Rate Three Color Marker (srTCM) in Packet per second mode */
+	RTE_MTR_SRTCM_PPS,
 };
 
 /**
@@ -171,6 +174,18 @@ struct rte_mtr_meter_profile {
 			/** Excess Burst Size (EBS) (bytes). */
 			uint64_t ebs;
 		} trtcm_rfc4115;
+
+		/** Items only valid when *alg* is set to srTCM - PPS. */
+		struct {
+			/** Committed Information Rate (CIR)(packets/second). */
+			uint64_t cir;
+
+			/** Committed Burst Size (CBS) (bytes). */
+			uint64_t cbs;
+
+			/** Excess Burst Size (EBS) (bytes). */
+			uint64_t ebs;
+		} srtcm_pps;
 	};
 };
 
@@ -317,6 +332,13 @@ struct rte_mtr_capabilities {
 	 */
 	uint32_t meter_trtcm_rfc4115_n_max;
 
+	/** Maximum number of MTR objects that can have their meter configured
+	 * to run the srTCM packet per second algorithm. The value of 0 
+	 * indicates this metering algorithm is not supported. 
+	 * The maximum value is *n_max*.
+	 */
+	uint32_t meter_srtcm_pps_n_max;
+
 	/** Maximum traffic rate that can be metered by a single MTR object. For
 	 * srTCM RFC 2697, this is the maximum CIR rate. For trTCM RFC 2698,
 	 * this is the maximum PIR rate. For trTCM RFC 4115, this is the maximum
@@ -342,6 +364,12 @@ struct rte_mtr_capabilities {
 	 */
 	int color_aware_trtcm_rfc4115_supported;
 
+	/**
+	* When non-zero, it indicates that color aware mode is supported for
+	* the srTCM packet per second  metering algorithm.
+	*/
+	int color_aware_srtcm_pps_supported;
+
 	/** When non-zero, it indicates that the policer packet recolor actions
 	 * are supported.
 	 * @see enum rte_mtr_policer_action
-- 
2.21.0

[dpdk-dev] [RFC 0/1] lib/librte_ethdev: Meter algorithms support packet per second.

[Li Zhang]

Li Zhang (1):
  lib/librte_ethdev: add definitions for packet per second.

 lib/librte_ethdev/rte_mtr.h | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

-- 
2.27.0

[dpdk-dev] [PATCH] [RFC, v2]: adds support PPS(packet per second) on meter

[Li Zhang]

Currently the flow Meter algorithms in rte_flow
only supports bytes per second(BPS).
Such as Single Rate Three Color Marker (srTCM rfc2697)
This RFC adds the packet per second definition in
Meter algorithms structure,
to support the rte_mtr APIs with type srTCM pps mode.
The below structure will be extended:
rte_mtr_algorithm
rte_mtr_meter_profile
Signed-off-by: Li Zhang <lizh@nvidia.com>
---
 lib/librte_ethdev/rte_mtr.h | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/lib/librte_ethdev/rte_mtr.h b/lib/librte_ethdev/rte_mtr.h
index 916a09c5c3..3e88904faf 100644
--- a/lib/librte_ethdev/rte_mtr.h
+++ b/lib/librte_ethdev/rte_mtr.h
@@ -119,6 +119,9 @@ enum rte_mtr_algorithm {
 
 	/** Two Rate Three Color Marker (trTCM) - IETF RFC 4115. */
 	RTE_MTR_TRTCM_RFC4115,
+
+	/** Single Rate Three Color Marker (srTCM) in Packet per second mode */
+	RTE_MTR_SRTCM_PPS,
 };
 
 /**
@@ -171,6 +174,18 @@ struct rte_mtr_meter_profile {
 			/** Excess Burst Size (EBS) (bytes). */
 			uint64_t ebs;
 		} trtcm_rfc4115;
+
+		/** Items only valid when *alg* is set to srTCM - PPS. */
+		struct {
+			/** Committed Information Rate (CIR)(packets/second). */
+			uint64_t cir;
+
+			/** Committed Burst Size (CBS) (bytes). */
+			uint64_t cbs;
+
+			/** Excess Burst Size (EBS) (bytes). */
+			uint64_t ebs;
+		} srtcm_pps;
 	};
 };
 
@@ -317,6 +332,13 @@ struct rte_mtr_capabilities {
 	 */
 	uint32_t meter_trtcm_rfc4115_n_max;
 
+	/** Maximum number of MTR objects that can have their meter configured
+	 * to run the srTCM packet per second algorithm. The value of 0
+	 * indicates this metering algorithm is not supported.
+	 * The maximum value is *n_max*.
+	 */
+	uint32_t meter_srtcm_pps_n_max;
+
 	/** Maximum traffic rate that can be metered by a single MTR object. For
 	 * srTCM RFC 2697, this is the maximum CIR rate. For trTCM RFC 2698,
 	 * this is the maximum PIR rate. For trTCM RFC 4115, this is the maximum
@@ -342,6 +364,12 @@ struct rte_mtr_capabilities {
 	 */
 	int color_aware_trtcm_rfc4115_supported;
 
+	/**
+	 * When non-zero, it indicates that color aware mode is supported for
+	 * the srTCM packet per second  metering algorithm.
+	 */
+	int color_aware_srtcm_pps_supported;
+
 	/** When non-zero, it indicates that the policer packet recolor actions
 	 * are supported.
 	 * @see enum rte_mtr_policer_action
-- 
2.21.0

Re: [dpdk-dev] [PATCH] [RFC, v2]: adds support PPS(packet per second) on meter

[Ferruh Yigit]

On 1/25/2021 1:20 AM, Li Zhang wrote:
> Currently the flow Meter algorithms in rte_flow
> only supports bytes per second(BPS).
> Such as Single Rate Three Color Marker (srTCM rfc2697)
> This RFC adds the packet per second definition in
> Meter algorithms structure,
> to support the rte_mtr APIs with type srTCM pps mode.
> The below structure will be extended:
> rte_mtr_algorithm
> rte_mtr_meter_profile
> Signed-off-by: Li Zhang <lizh@nvidia.com>

cc'ed Cristian for review/comment.

> ---
>   lib/librte_ethdev/rte_mtr.h | 28 ++++++++++++++++++++++++++++
>   1 file changed, 28 insertions(+)
> 
> diff --git a/lib/librte_ethdev/rte_mtr.h b/lib/librte_ethdev/rte_mtr.h
> index 916a09c5c3..3e88904faf 100644
> --- a/lib/librte_ethdev/rte_mtr.h
> +++ b/lib/librte_ethdev/rte_mtr.h
> @@ -119,6 +119,9 @@ enum rte_mtr_algorithm {
>   
>   	/** Two Rate Three Color Marker (trTCM) - IETF RFC 4115. */
>   	RTE_MTR_TRTCM_RFC4115,
> +
> +	/** Single Rate Three Color Marker (srTCM) in Packet per second mode */
> +	RTE_MTR_SRTCM_PPS,
>   };
>   
>   /**
> @@ -171,6 +174,18 @@ struct rte_mtr_meter_profile {
>   			/** Excess Burst Size (EBS) (bytes). */
>   			uint64_t ebs;
>   		} trtcm_rfc4115;
> +
> +		/** Items only valid when *alg* is set to srTCM - PPS. */
> +		struct {
> +			/** Committed Information Rate (CIR)(packets/second). */
> +			uint64_t cir;
> +
> +			/** Committed Burst Size (CBS) (bytes). */
> +			uint64_t cbs;
> +
> +			/** Excess Burst Size (EBS) (bytes). */
> +			uint64_t ebs;
> +		} srtcm_pps;
>   	};
>   };
>   
> @@ -317,6 +332,13 @@ struct rte_mtr_capabilities {
>   	 */
>   	uint32_t meter_trtcm_rfc4115_n_max;
>   
> +	/** Maximum number of MTR objects that can have their meter configured
> +	 * to run the srTCM packet per second algorithm. The value of 0
> +	 * indicates this metering algorithm is not supported.
> +	 * The maximum value is *n_max*.
> +	 */
> +	uint32_t meter_srtcm_pps_n_max;
> +
>   	/** Maximum traffic rate that can be metered by a single MTR object. For
>   	 * srTCM RFC 2697, this is the maximum CIR rate. For trTCM RFC 2698,
>   	 * this is the maximum PIR rate. For trTCM RFC 4115, this is the maximum
> @@ -342,6 +364,12 @@ struct rte_mtr_capabilities {
>   	 */
>   	int color_aware_trtcm_rfc4115_supported;
>   
> +	/**
> +	 * When non-zero, it indicates that color aware mode is supported for
> +	 * the srTCM packet per second  metering algorithm.
> +	 */
> +	int color_aware_srtcm_pps_supported;
> +
>   	/** When non-zero, it indicates that the policer packet recolor actions
>   	 * are supported.
>   	 * @see enum rte_mtr_policer_action
> 

Re: [dpdk-dev] [PATCH] [RFC, v2]: adds support PPS(packet per second) on meter

[Morten Brørup]

> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ferruh Yigit
> Sent: Thursday, January 28, 2021 7:28 PM
> 
> On 1/25/2021 1:20 AM, Li Zhang wrote:
> > Currently the flow Meter algorithms in rte_flow
> > only supports bytes per second(BPS).
> > Such as Single Rate Three Color Marker (srTCM rfc2697)
> > This RFC adds the packet per second definition in
> > Meter algorithms structure,
> > to support the rte_mtr APIs with type srTCM pps mode.
> > The below structure will be extended:
> > rte_mtr_algorithm
> > rte_mtr_meter_profile
> > Signed-off-by: Li Zhang <lizh@nvidia.com>
> 
> cc'ed Cristian for review/comment.
> 
> > ---
> >   lib/librte_ethdev/rte_mtr.h | 28 ++++++++++++++++++++++++++++
> >   1 file changed, 28 insertions(+)
> >
> > diff --git a/lib/librte_ethdev/rte_mtr.h
> b/lib/librte_ethdev/rte_mtr.h
> > index 916a09c5c3..3e88904faf 100644
> > --- a/lib/librte_ethdev/rte_mtr.h
> > +++ b/lib/librte_ethdev/rte_mtr.h
> > @@ -119,6 +119,9 @@ enum rte_mtr_algorithm {
> >
> >   	/** Two Rate Three Color Marker (trTCM) - IETF RFC 4115. */
> >   	RTE_MTR_TRTCM_RFC4115,
> > +
> > +	/** Single Rate Three Color Marker (srTCM) in Packet per second
> mode */
> > +	RTE_MTR_SRTCM_PPS,
> >   };
> >
> >   /**
> > @@ -171,6 +174,18 @@ struct rte_mtr_meter_profile {
> >   			/** Excess Burst Size (EBS) (bytes). */
> >   			uint64_t ebs;
> >   		} trtcm_rfc4115;
> > +
> > +		/** Items only valid when *alg* is set to srTCM - PPS. */
> > +		struct {
> > +			/** Committed Information Rate (CIR)(packets/second).
> */
> > +			uint64_t cir;
> > +
> > +			/** Committed Burst Size (CBS) (bytes). */
> > +			uint64_t cbs;
> > +
> > +			/** Excess Burst Size (EBS) (bytes). */
> > +			uint64_t ebs;
> > +		} srtcm_pps;

In PPS mode, the burst sizes (ebs, ebs) must be packets, not bytes.

> >   	};
> >   };
> >
> > @@ -317,6 +332,13 @@ struct rte_mtr_capabilities {
> >   	 */
> >   	uint32_t meter_trtcm_rfc4115_n_max;
> >
> > +	/** Maximum number of MTR objects that can have their meter
> configured
> > +	 * to run the srTCM packet per second algorithm. The value of 0
> > +	 * indicates this metering algorithm is not supported.
> > +	 * The maximum value is *n_max*.
> > +	 */
> > +	uint32_t meter_srtcm_pps_n_max;
> > +
> >   	/** Maximum traffic rate that can be metered by a single MTR
> object. For
> >   	 * srTCM RFC 2697, this is the maximum CIR rate. For trTCM RFC
> 2698,
> >   	 * this is the maximum PIR rate. For trTCM RFC 4115, this is the
> maximum
> > @@ -342,6 +364,12 @@ struct rte_mtr_capabilities {
> >   	 */
> >   	int color_aware_trtcm_rfc4115_supported;
> >
> > +	/**
> > +	 * When non-zero, it indicates that color aware mode is supported
> for
> > +	 * the srTCM packet per second  metering algorithm.

No need for two spaces between the words second and metering.

> > +	 */
> > +	int color_aware_srtcm_pps_supported;
> > +
> >   	/** When non-zero, it indicates that the policer packet recolor
> actions
> >   	 * are supported.
> >   	 * @see enum rte_mtr_policer_action
> >
> 

Re: [dpdk-dev] [PATCH] [RFC, v2]: adds support PPS(packet per second) on meter

[Li Zhang]

Thanks for your comments.
We changed the struct as below:
struct rte_mtr_meter_profile {
 ......
		/** Items only valid when alg is set to sprTCM. */
		struct {
			/** Committed Information Packet Rate (CIPR). */
			uint64_t cipr;

			/** Committed Packet Burst Size (CPBS). */
			uint64_t cpbs;

			/** Excess Packet Burst Size (EPBS). */
			uint64_t epbs;
		} sprtcm;
}

Regards,
Li Zhang
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Morten Br?rup
> Sent: Friday, February 12, 2021 3:41 PM
> To: Ferruh Yigit <ferruh.yigit@intel.com>; Li Zhang <lizh@nvidia.com>; Dekel
> Peled <dekelp@nvidia.com>; Ori Kam <orika@nvidia.com>; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Matan Azrad <matan@nvidia.com>; Dumitrescu,
> Cristian <cristian.dumitrescu@intel.com>
> Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon <thomas@monjalon.net>;
> Raslan Darawsheh <rasland@nvidia.com>
> Subject: Re: [dpdk-dev] [PATCH] [RFC, v2]: adds support PPS(packet per second)
> on meter
> 
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ferruh Yigit
> > Sent: Thursday, January 28, 2021 7:28 PM
> >
> > On 1/25/2021 1:20 AM, Li Zhang wrote:
> > > Currently the flow Meter algorithms in rte_flow only supports bytes
> > > per second(BPS).
> > > Such as Single Rate Three Color Marker (srTCM rfc2697) This RFC adds
> > > the packet per second definition in Meter algorithms structure, to
> > > support the rte_mtr APIs with type srTCM pps mode.
> > > The below structure will be extended:
> > > rte_mtr_algorithm
> > > rte_mtr_meter_profile
> > > Signed-off-by: Li Zhang <lizh@nvidia.com>
> >
> > cc'ed Cristian for review/comment.
> >
> > > ---
> > >   lib/librte_ethdev/rte_mtr.h | 28 ++++++++++++++++++++++++++++
> > >   1 file changed, 28 insertions(+)
> > >
> > > diff --git a/lib/librte_ethdev/rte_mtr.h
> > b/lib/librte_ethdev/rte_mtr.h
> > > index 916a09c5c3..3e88904faf 100644
> > > --- a/lib/librte_ethdev/rte_mtr.h
> > > +++ b/lib/librte_ethdev/rte_mtr.h
> > > @@ -119,6 +119,9 @@ enum rte_mtr_algorithm {
> > >
> > >   	/** Two Rate Three Color Marker (trTCM) - IETF RFC 4115. */
> > >   	RTE_MTR_TRTCM_RFC4115,
> > > +
> > > +	/** Single Rate Three Color Marker (srTCM) in Packet per second
> > mode */
> > > +	RTE_MTR_SRTCM_PPS,
> > >   };
> > >
> > >   /**
> > > @@ -171,6 +174,18 @@ struct rte_mtr_meter_profile {
> > >   			/** Excess Burst Size (EBS) (bytes). */
> > >   			uint64_t ebs;
> > >   		} trtcm_rfc4115;
> > > +
> > > +		/** Items only valid when *alg* is set to srTCM - PPS. */
> > > +		struct {
> > > +			/** Committed Information Rate
> (CIR)(packets/second).
> > */
> > > +			uint64_t cir;
> > > +
> > > +			/** Committed Burst Size (CBS) (bytes). */
> > > +			uint64_t cbs;
> > > +
> > > +			/** Excess Burst Size (EBS) (bytes). */
> > > +			uint64_t ebs;
> > > +		} srtcm_pps;
> 
> In PPS mode, the burst sizes (ebs, ebs) must be packets, not bytes.
> 
> > >   	};
> > >   };
> > >
> > > @@ -317,6 +332,13 @@ struct rte_mtr_capabilities {
> > >   	 */
> > >   	uint32_t meter_trtcm_rfc4115_n_max;
> > >
> > > +	/** Maximum number of MTR objects that can have their meter
> > configured
> > > +	 * to run the srTCM packet per second algorithm. The value of 0
> > > +	 * indicates this metering algorithm is not supported.
> > > +	 * The maximum value is *n_max*.
> > > +	 */
> > > +	uint32_t meter_srtcm_pps_n_max;
> > > +
> > >   	/** Maximum traffic rate that can be metered by a single MTR
> > object. For
> > >   	 * srTCM RFC 2697, this is the maximum CIR rate. For trTCM RFC
> > 2698,
> > >   	 * this is the maximum PIR rate. For trTCM RFC 4115, this is the
> > maximum
> > > @@ -342,6 +364,12 @@ struct rte_mtr_capabilities {
> > >   	 */
> > >   	int color_aware_trtcm_rfc4115_supported;
> > >
> > > +	/**
> > > +	 * When non-zero, it indicates that color aware mode is supported
> > for
> > > +	 * the srTCM packet per second  metering algorithm.
> 
> No need for two spaces between the words second and metering.
> 
> > > +	 */
> > > +	int color_aware_srtcm_pps_supported;
> > > +
> > >   	/** When non-zero, it indicates that the policer packet recolor
> > actions
> > >   	 * are supported.
> > >   	 * @see enum rte_mtr_policer_action
> > >
> >

Re: [dpdk-dev] [PATCH] [RFC, v2]: adds support PPS(packet per second) on meter

[Morten Brørup]

> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Li Zhang
> Sent: Tuesday, February 23, 2021 3:07 AM
> 
> Thanks for your comments.
> We changed the struct as below:
> struct rte_mtr_meter_profile {
>  ......
> 		/** Items only valid when alg is set to sprTCM. */
> 		struct {
> 			/** Committed Information Packet Rate (CIPR). */
> 			uint64_t cipr;
> 
> 			/** Committed Packet Burst Size (CPBS). */
> 			uint64_t cpbs;
> 
> 			/** Excess Packet Burst Size (EPBS). */
> 			uint64_t epbs;
> 		} sprtcm;
> }

That is certainly not an improvement! Please stick with the broadly accepted industry standard names (CIR, CBS, EBS, etc.). Newly invented names like CIPR will only cause confusion. Please note that CIR, CBS, EBS don't say anything about their units; it could be bytes, packets, cells, frames, messages or anything else. So it is perfectly natural using the same names for packets instead of bytes.

I propose the following modifications instead.

For the algorithm, keep the "Single Rate Three Color Marker" name mentioned in the RFCs, but indicate that the variant is packet based:

	/** Single Rate Three Color Marker, Packet based (srTCMp). */
	RTE_MTR_SRTCMP,

Or if you prefer the packet based indicator at the front instead:

	/** Packet based Single Rate Three Color Marker (psrTCM). */
	RTE_MTR_PSRTCM,

And for the meter profile, keep the industry standard names, but update the descriptions:

 		/** Items only valid when *alg* is set to srTCMp. */
 		struct {
 			/** Committed Information Rate (CIR) (packets/second). */
 			uint64_t cir;
 
 			/** Committed Burst Size (CBS) (packets). */
 			uint64_t cbs;
 
 			/** Excess Burst Size (EBS) (packets). */
 			uint64_t ebs;
 		} srtcmp;


Come to think of it: Is the unit packets, or is it actually Ethernet frames? In other words: Does a 4 KB TCP packet that the NIC's offload function chops up into three Ethernet frames count as one or three in this algorithm?


Med venlig hilsen / kind regards
- Morten Brørup

> 
> Regards,
> Li Zhang
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Morten Br?rup
> > Sent: Friday, February 12, 2021 3:41 PM
> > To: Ferruh Yigit <ferruh.yigit@intel.com>; Li Zhang
> <lizh@nvidia.com>; Dekel
> > Peled <dekelp@nvidia.com>; Ori Kam <orika@nvidia.com>; Slava
> Ovsiienko
> > <viacheslavo@nvidia.com>; Matan Azrad <matan@nvidia.com>; Dumitrescu,
> > Cristian <cristian.dumitrescu@intel.com>
> > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon <thomas@monjalon.net>;
> > Raslan Darawsheh <rasland@nvidia.com>
> > Subject: Re: [dpdk-dev] [PATCH] [RFC, v2]: adds support PPS(packet
> per second)
> > on meter
> >
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ferruh Yigit
> > > Sent: Thursday, January 28, 2021 7:28 PM
> > >
> > > On 1/25/2021 1:20 AM, Li Zhang wrote:
> > > > Currently the flow Meter algorithms in rte_flow only supports
> bytes
> > > > per second(BPS).
> > > > Such as Single Rate Three Color Marker (srTCM rfc2697) This RFC
> adds
> > > > the packet per second definition in Meter algorithms structure,
> to
> > > > support the rte_mtr APIs with type srTCM pps mode.
> > > > The below structure will be extended:
> > > > rte_mtr_algorithm
> > > > rte_mtr_meter_profile
> > > > Signed-off-by: Li Zhang <lizh@nvidia.com>
> > >
> > > cc'ed Cristian for review/comment.
> > >
> > > > ---
> > > >   lib/librte_ethdev/rte_mtr.h | 28 ++++++++++++++++++++++++++++
> > > >   1 file changed, 28 insertions(+)
> > > >
> > > > diff --git a/lib/librte_ethdev/rte_mtr.h
> > > b/lib/librte_ethdev/rte_mtr.h
> > > > index 916a09c5c3..3e88904faf 100644
> > > > --- a/lib/librte_ethdev/rte_mtr.h
> > > > +++ b/lib/librte_ethdev/rte_mtr.h
> > > > @@ -119,6 +119,9 @@ enum rte_mtr_algorithm {
> > > >
> > > >   	/** Two Rate Three Color Marker (trTCM) - IETF RFC 4115. */
> > > >   	RTE_MTR_TRTCM_RFC4115,
> > > > +
> > > > +	/** Single Rate Three Color Marker (srTCM) in Packet per
> second
> > > mode */
> > > > +	RTE_MTR_SRTCM_PPS,
> > > >   };
> > > >
> > > >   /**
> > > > @@ -171,6 +174,18 @@ struct rte_mtr_meter_profile {
> > > >   			/** Excess Burst Size (EBS) (bytes). */
> > > >   			uint64_t ebs;
> > > >   		} trtcm_rfc4115;
> > > > +
> > > > +		/** Items only valid when *alg* is set to srTCM -
> PPS. */
> > > > +		struct {
> > > > +			/** Committed Information Rate
> > (CIR)(packets/second).
> > > */
> > > > +			uint64_t cir;
> > > > +
> > > > +			/** Committed Burst Size (CBS) (bytes). */
> > > > +			uint64_t cbs;
> > > > +
> > > > +			/** Excess Burst Size (EBS) (bytes). */
> > > > +			uint64_t ebs;
> > > > +		} srtcm_pps;
> >
> > In PPS mode, the burst sizes (ebs, ebs) must be packets, not bytes.
> >
> > > >   	};
> > > >   };
> > > >
> > > > @@ -317,6 +332,13 @@ struct rte_mtr_capabilities {
> > > >   	 */
> > > >   	uint32_t meter_trtcm_rfc4115_n_max;
> > > >
> > > > +	/** Maximum number of MTR objects that can have their meter
> > > configured
> > > > +	 * to run the srTCM packet per second algorithm. The value
> of 0
> > > > +	 * indicates this metering algorithm is not supported.
> > > > +	 * The maximum value is *n_max*.
> > > > +	 */
> > > > +	uint32_t meter_srtcm_pps_n_max;
> > > > +
> > > >   	/** Maximum traffic rate that can be metered by a single
> MTR
> > > object. For
> > > >   	 * srTCM RFC 2697, this is the maximum CIR rate. For trTCM
> RFC
> > > 2698,
> > > >   	 * this is the maximum PIR rate. For trTCM RFC 4115, this
> is the
> > > maximum
> > > > @@ -342,6 +364,12 @@ struct rte_mtr_capabilities {
> > > >   	 */
> > > >   	int color_aware_trtcm_rfc4115_supported;
> > > >
> > > > +	/**
> > > > +	 * When non-zero, it indicates that color aware mode is
> supported
> > > for
> > > > +	 * the srTCM packet per second  metering algorithm.
> >
> > No need for two spaces between the words second and metering.
> >
> > > > +	 */
> > > > +	int color_aware_srtcm_pps_supported;
> > > > +
> > > >   	/** When non-zero, it indicates that the policer packet
> recolor
> > > actions
> > > >   	 * are supported.
> > > >   	 * @see enum rte_mtr_policer_action
> > > >
> > >

Re: [dpdk-dev] [PATCH] [RFC, v2]: adds support PPS(packet per second) on meter

[Li Zhang]

Hi Morten,

Thank you for your comments.
It is packet count instead of frames count.
So 4K TCP packet should be handle as one instead of 3 Ethernet Frames.

We will update the struct as below:
enum rte_mtr_algorithm {
......
	/** Single Rate Three Color Marker, Packet based (srTCMp).
	 * - - similar to IETF RFC 2697 but rate is packet per second.
	 */
	RTE_MTR_SRTCMP,
}
	
struct rte_mtr_meter_profile {
......		
		/** Items only valid when *alg* is set to srTCMp. */
		struct {
			/** Committed Information Rate (CIR)
			 * (packets/second).
			 */
			uint64_t cir;

			/** Committed Burst Size (CBS) (packets). */
			uint64_t cbs;

			/** Excess Burst Size (EBS) (packets). */
			uint64_t ebs;
		} srtcmp;
}

Regards,
Li Zhang
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Morten Br?rup
> Sent: Tuesday, February 23, 2021 4:25 PM
> To: Li Zhang <lizh@nvidia.com>; Ferruh Yigit <ferruh.yigit@intel.com>; Dekel
> Peled <dekelp@nvidia.com>; Ori Kam <orika@nvidia.com>; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Matan Azrad <matan@nvidia.com>; Dumitrescu,
> Cristian <cristian.dumitrescu@intel.com>
> Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon <thomas@monjalon.net>;
> Raslan Darawsheh <rasland@nvidia.com>
> Subject: Re: [dpdk-dev] [PATCH] [RFC, v2]: adds support PPS(packet per second)
> on meter
> 
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Li Zhang
> > Sent: Tuesday, February 23, 2021 3:07 AM
> >
> > Thanks for your comments.
> > We changed the struct as below:
> > struct rte_mtr_meter_profile {
> >  ......
> > 		/** Items only valid when alg is set to sprTCM. */
> > 		struct {
> > 			/** Committed Information Packet Rate (CIPR). */
> > 			uint64_t cipr;
> >
> > 			/** Committed Packet Burst Size (CPBS). */
> > 			uint64_t cpbs;
> >
> > 			/** Excess Packet Burst Size (EPBS). */
> > 			uint64_t epbs;
> > 		} sprtcm;
> > }
> 
> That is certainly not an improvement! Please stick with the broadly accepted
> industry standard names (CIR, CBS, EBS, etc.). Newly invented names like CIPR
> will only cause confusion. Please note that CIR, CBS, EBS don't say anything
> about their units; it could be bytes, packets, cells, frames, messages or
> anything else. So it is perfectly natural using the same names for packets
> instead of bytes.
> 
> I propose the following modifications instead.
> 
> For the algorithm, keep the "Single Rate Three Color Marker" name mentioned
> in the RFCs, but indicate that the variant is packet based:
> 
> 	/** Single Rate Three Color Marker, Packet based (srTCMp). */
> 	RTE_MTR_SRTCMP,
> 
> Or if you prefer the packet based indicator at the front instead:
> 
> 	/** Packet based Single Rate Three Color Marker (psrTCM). */
> 	RTE_MTR_PSRTCM,
> 
> And for the meter profile, keep the industry standard names, but update the
> descriptions:
> 
>  		/** Items only valid when *alg* is set to srTCMp. */
>  		struct {
>  			/** Committed Information Rate (CIR)
> (packets/second). */
>  			uint64_t cir;
> 
>  			/** Committed Burst Size (CBS) (packets). */
>  			uint64_t cbs;
> 
>  			/** Excess Burst Size (EBS) (packets). */
>  			uint64_t ebs;
>  		} srtcmp;
> 
> 
> Come to think of it: Is the unit packets, or is it actually Ethernet frames? In
> other words: Does a 4 KB TCP packet that the NIC's offload function chops up
> into three Ethernet frames count as one or three in this algorithm?
> 
> 
> Med venlig hilsen / kind regards
> - Morten Brørup
> 
> >
> > Regards,
> > Li Zhang
> > > -----Original Message-----
> > > From: dev <dev-bounces@dpdk.org> On Behalf Of Morten Br?rup
> > > Sent: Friday, February 12, 2021 3:41 PM
> > > To: Ferruh Yigit <ferruh.yigit@intel.com>; Li Zhang
> > <lizh@nvidia.com>; Dekel
> > > Peled <dekelp@nvidia.com>; Ori Kam <orika@nvidia.com>; Slava
> > Ovsiienko
> > > <viacheslavo@nvidia.com>; Matan Azrad <matan@nvidia.com>;
> > > Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> > > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon
> <thomas@monjalon.net>;
> > > Raslan Darawsheh <rasland@nvidia.com>
> > > Subject: Re: [dpdk-dev] [PATCH] [RFC, v2]: adds support PPS(packet
> > per second)
> > > on meter
> > >
> > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ferruh Yigit
> > > > Sent: Thursday, January 28, 2021 7:28 PM
> > > >
> > > > On 1/25/2021 1:20 AM, Li Zhang wrote:
> > > > > Currently the flow Meter algorithms in rte_flow only supports
> > bytes
> > > > > per second(BPS).
> > > > > Such as Single Rate Three Color Marker (srTCM rfc2697) This RFC
> > adds
> > > > > the packet per second definition in Meter algorithms structure,
> > to
> > > > > support the rte_mtr APIs with type srTCM pps mode.
> > > > > The below structure will be extended:
> > > > > rte_mtr_algorithm
> > > > > rte_mtr_meter_profile
> > > > > Signed-off-by: Li Zhang <lizh@nvidia.com>
> > > >
> > > > cc'ed Cristian for review/comment.
> > > >
> > > > > ---
> > > > >   lib/librte_ethdev/rte_mtr.h | 28 ++++++++++++++++++++++++++++
> > > > >   1 file changed, 28 insertions(+)
> > > > >
> > > > > diff --git a/lib/librte_ethdev/rte_mtr.h
> > > > b/lib/librte_ethdev/rte_mtr.h
> > > > > index 916a09c5c3..3e88904faf 100644
> > > > > --- a/lib/librte_ethdev/rte_mtr.h
> > > > > +++ b/lib/librte_ethdev/rte_mtr.h
> > > > > @@ -119,6 +119,9 @@ enum rte_mtr_algorithm {
> > > > >
> > > > >   	/** Two Rate Three Color Marker (trTCM) - IETF RFC 4115. */
> > > > >   	RTE_MTR_TRTCM_RFC4115,
> > > > > +
> > > > > +	/** Single Rate Three Color Marker (srTCM) in Packet per
> > second
> > > > mode */
> > > > > +	RTE_MTR_SRTCM_PPS,
> > > > >   };
> > > > >
> > > > >   /**
> > > > > @@ -171,6 +174,18 @@ struct rte_mtr_meter_profile {
> > > > >   			/** Excess Burst Size (EBS) (bytes). */
> > > > >   			uint64_t ebs;
> > > > >   		} trtcm_rfc4115;
> > > > > +
> > > > > +		/** Items only valid when *alg* is set to srTCM -
> > PPS. */
> > > > > +		struct {
> > > > > +			/** Committed Information Rate
> > > (CIR)(packets/second).
> > > > */
> > > > > +			uint64_t cir;
> > > > > +
> > > > > +			/** Committed Burst Size (CBS) (bytes). */
> > > > > +			uint64_t cbs;
> > > > > +
> > > > > +			/** Excess Burst Size (EBS) (bytes). */
> > > > > +			uint64_t ebs;
> > > > > +		} srtcm_pps;
> > >
> > > In PPS mode, the burst sizes (ebs, ebs) must be packets, not bytes.
> > >
> > > > >   	};
> > > > >   };
> > > > >
> > > > > @@ -317,6 +332,13 @@ struct rte_mtr_capabilities {
> > > > >   	 */
> > > > >   	uint32_t meter_trtcm_rfc4115_n_max;
> > > > >
> > > > > +	/** Maximum number of MTR objects that can have their
> meter
> > > > configured
> > > > > +	 * to run the srTCM packet per second algorithm. The value
> > of 0
> > > > > +	 * indicates this metering algorithm is not supported.
> > > > > +	 * The maximum value is *n_max*.
> > > > > +	 */
> > > > > +	uint32_t meter_srtcm_pps_n_max;
> > > > > +
> > > > >   	/** Maximum traffic rate that can be metered by a single
> > MTR
> > > > object. For
> > > > >   	 * srTCM RFC 2697, this is the maximum CIR rate. For trTCM
> > RFC
> > > > 2698,
> > > > >   	 * this is the maximum PIR rate. For trTCM RFC 4115, this
> > is the
> > > > maximum
> > > > > @@ -342,6 +364,12 @@ struct rte_mtr_capabilities {
> > > > >   	 */
> > > > >   	int color_aware_trtcm_rfc4115_supported;
> > > > >
> > > > > +	/**
> > > > > +	 * When non-zero, it indicates that color aware mode is
> > supported
> > > > for
> > > > > +	 * the srTCM packet per second  metering algorithm.
> > >
> > > No need for two spaces between the words second and metering.
> > >
> > > > > +	 */
> > > > > +	int color_aware_srtcm_pps_supported;
> > > > > +
> > > > >   	/** When non-zero, it indicates that the policer packet
> > recolor
> > > > actions
> > > > >   	 * are supported.
> > > > >   	 * @see enum rte_mtr_policer_action
> > > > >
> > > >

Re: [dpdk-dev] [PATCH] [RFC, v2]: adds support PPS(packet per second) on meter

[Ajit Khaparde]

[-- Attachment #1: Type: text/plain, Size: 1152 bytes --]

On Sun, Feb 28, 2021 at 7:16 PM Li Zhang <lizh@nvidia.com> wrote:
>
> Hi Morten,
>
> Thank you for your comments.
> It is packet count instead of frames count.
> So 4K TCP packet should be handle as one instead of 3 Ethernet Frames.
So it is not dependent on the MTU?

>
> We will update the struct as below:
> enum rte_mtr_algorithm {
> ......
>         /** Single Rate Three Color Marker, Packet based (srTCMp).
+1

>          * - - similar to IETF RFC 2697 but rate is packet per second.
s/rate is/measured in

>          */
>         RTE_MTR_SRTCMP,
> }
>
> struct rte_mtr_meter_profile {
> ......
>                 /** Items only valid when *alg* is set to srTCMp. */
>                 struct {
>                         /** Committed Information Rate (CIR)
>                          * (packets/second).
>                          */
>                         uint64_t cir;
>
>                         /** Committed Burst Size (CBS) (packets). */
>                         uint64_t cbs;
>
>                         /** Excess Burst Size (EBS) (packets). */
>                         uint64_t ebs;
>                 } srtcmp;
> }
>
::::[snip]::::

Re: [dpdk-dev] [PATCH] [RFC, v2]: adds support PPS(packet per second) on meter

[Morten Brørup]

> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Li Zhang
> Sent: Monday, March 1, 2021 4:16 AM
> 
> Hi Morten,
> 
> Thank you for your comments.
> It is packet count instead of frames count.
> So 4K TCP packet should be handle as one instead of 3 Ethernet Frames.
> 
> We will update the struct as below:
> enum rte_mtr_algorithm {
> ......
> 	/** Single Rate Three Color Marker, Packet based (srTCMp).
> 	 * - - similar to IETF RFC 2697 but rate is packet per second.
> 	 */
> 	RTE_MTR_SRTCMP,
> }
> 
> struct rte_mtr_meter_profile {
> ......
> 		/** Items only valid when *alg* is set to srTCMp. */
> 		struct {
> 			/** Committed Information Rate (CIR)
> 			 * (packets/second).
> 			 */
> 			uint64_t cir;
> 
> 			/** Committed Burst Size (CBS) (packets). */
> 			uint64_t cbs;
> 
> 			/** Excess Burst Size (EBS) (packets). */
> 			uint64_t ebs;
> 		} srtcmp;
> }
> 
> Regards,
> Li Zhang

Looks good.

Acked-By: Morten Brørup <mb@smartsharesystems.com>


> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Morten Br?rup
> > Sent: Tuesday, February 23, 2021 4:25 PM
> > To: Li Zhang <lizh@nvidia.com>; Ferruh Yigit
> <ferruh.yigit@intel.com>; Dekel
> > Peled <dekelp@nvidia.com>; Ori Kam <orika@nvidia.com>; Slava
> Ovsiienko
> > <viacheslavo@nvidia.com>; Matan Azrad <matan@nvidia.com>; Dumitrescu,
> > Cristian <cristian.dumitrescu@intel.com>
> > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon <thomas@monjalon.net>;
> > Raslan Darawsheh <rasland@nvidia.com>
> > Subject: Re: [dpdk-dev] [PATCH] [RFC, v2]: adds support PPS(packet
> per second)
> > on meter
> >
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Li Zhang
> > > Sent: Tuesday, February 23, 2021 3:07 AM
> > >
> > > Thanks for your comments.
> > > We changed the struct as below:
> > > struct rte_mtr_meter_profile {
> > >  ......
> > > 		/** Items only valid when alg is set to sprTCM. */
> > > 		struct {
> > > 			/** Committed Information Packet Rate (CIPR). */
> > > 			uint64_t cipr;
> > >
> > > 			/** Committed Packet Burst Size (CPBS). */
> > > 			uint64_t cpbs;
> > >
> > > 			/** Excess Packet Burst Size (EPBS). */
> > > 			uint64_t epbs;
> > > 		} sprtcm;
> > > }
> >
> > That is certainly not an improvement! Please stick with the broadly
> accepted
> > industry standard names (CIR, CBS, EBS, etc.). Newly invented names
> like CIPR
> > will only cause confusion. Please note that CIR, CBS, EBS don't say
> anything
> > about their units; it could be bytes, packets, cells, frames,
> messages or
> > anything else. So it is perfectly natural using the same names for
> packets
> > instead of bytes.
> >
> > I propose the following modifications instead.
> >
> > For the algorithm, keep the "Single Rate Three Color Marker" name
> mentioned
> > in the RFCs, but indicate that the variant is packet based:
> >
> > 	/** Single Rate Three Color Marker, Packet based (srTCMp). */
> > 	RTE_MTR_SRTCMP,
> >
> > Or if you prefer the packet based indicator at the front instead:
> >
> > 	/** Packet based Single Rate Three Color Marker (psrTCM). */
> > 	RTE_MTR_PSRTCM,
> >
> > And for the meter profile, keep the industry standard names, but
> update the
> > descriptions:
> >
> >  		/** Items only valid when *alg* is set to srTCMp. */
> >  		struct {
> >  			/** Committed Information Rate (CIR)
> > (packets/second). */
> >  			uint64_t cir;
> >
> >  			/** Committed Burst Size (CBS) (packets). */
> >  			uint64_t cbs;
> >
> >  			/** Excess Burst Size (EBS) (packets). */
> >  			uint64_t ebs;
> >  		} srtcmp;
> >
> >
> > Come to think of it: Is the unit packets, or is it actually Ethernet
> frames? In
> > other words: Does a 4 KB TCP packet that the NIC's offload function
> chops up
> > into three Ethernet frames count as one or three in this algorithm?
> >
> >
> > Med venlig hilsen / kind regards
> > - Morten Brørup
> >
> > >
> > > Regards,
> > > Li Zhang
> > > > -----Original Message-----
> > > > From: dev <dev-bounces@dpdk.org> On Behalf Of Morten Br?rup
> > > > Sent: Friday, February 12, 2021 3:41 PM
> > > > To: Ferruh Yigit <ferruh.yigit@intel.com>; Li Zhang
> > > <lizh@nvidia.com>; Dekel
> > > > Peled <dekelp@nvidia.com>; Ori Kam <orika@nvidia.com>; Slava
> > > Ovsiienko
> > > > <viacheslavo@nvidia.com>; Matan Azrad <matan@nvidia.com>;
> > > > Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> > > > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon
> > <thomas@monjalon.net>;
> > > > Raslan Darawsheh <rasland@nvidia.com>
> > > > Subject: Re: [dpdk-dev] [PATCH] [RFC, v2]: adds support
> PPS(packet
> > > per second)
> > > > on meter
> > > >
> > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ferruh
> Yigit
> > > > > Sent: Thursday, January 28, 2021 7:28 PM
> > > > >
> > > > > On 1/25/2021 1:20 AM, Li Zhang wrote:
> > > > > > Currently the flow Meter algorithms in rte_flow only supports
> > > bytes
> > > > > > per second(BPS).
> > > > > > Such as Single Rate Three Color Marker (srTCM rfc2697) This
> RFC
> > > adds
> > > > > > the packet per second definition in Meter algorithms
> structure,
> > > to
> > > > > > support the rte_mtr APIs with type srTCM pps mode.
> > > > > > The below structure will be extended:
> > > > > > rte_mtr_algorithm
> > > > > > rte_mtr_meter_profile
> > > > > > Signed-off-by: Li Zhang <lizh@nvidia.com>
> > > > >
> > > > > cc'ed Cristian for review/comment.
> > > > >
> > > > > > ---
> > > > > >   lib/librte_ethdev/rte_mtr.h | 28
> ++++++++++++++++++++++++++++
> > > > > >   1 file changed, 28 insertions(+)
> > > > > >
> > > > > > diff --git a/lib/librte_ethdev/rte_mtr.h
> > > > > b/lib/librte_ethdev/rte_mtr.h
> > > > > > index 916a09c5c3..3e88904faf 100644
> > > > > > --- a/lib/librte_ethdev/rte_mtr.h
> > > > > > +++ b/lib/librte_ethdev/rte_mtr.h
> > > > > > @@ -119,6 +119,9 @@ enum rte_mtr_algorithm {
> > > > > >
> > > > > >   	/** Two Rate Three Color Marker (trTCM) - IETF RFC
> 4115. */
> > > > > >   	RTE_MTR_TRTCM_RFC4115,
> > > > > > +
> > > > > > +	/** Single Rate Three Color Marker (srTCM) in Packet per
> > > second
> > > > > mode */
> > > > > > +	RTE_MTR_SRTCM_PPS,
> > > > > >   };
> > > > > >
> > > > > >   /**
> > > > > > @@ -171,6 +174,18 @@ struct rte_mtr_meter_profile {
> > > > > >   			/** Excess Burst Size (EBS) (bytes). */
> > > > > >   			uint64_t ebs;
> > > > > >   		} trtcm_rfc4115;
> > > > > > +
> > > > > > +		/** Items only valid when *alg* is set to srTCM -
> > > PPS. */
> > > > > > +		struct {
> > > > > > +			/** Committed Information Rate
> > > > (CIR)(packets/second).
> > > > > */
> > > > > > +			uint64_t cir;
> > > > > > +
> > > > > > +			/** Committed Burst Size (CBS) (bytes). */
> > > > > > +			uint64_t cbs;
> > > > > > +
> > > > > > +			/** Excess Burst Size (EBS) (bytes). */
> > > > > > +			uint64_t ebs;
> > > > > > +		} srtcm_pps;
> > > >
> > > > In PPS mode, the burst sizes (ebs, ebs) must be packets, not
> bytes.
> > > >
> > > > > >   	};
> > > > > >   };
> > > > > >
> > > > > > @@ -317,6 +332,13 @@ struct rte_mtr_capabilities {
> > > > > >   	 */
> > > > > >   	uint32_t meter_trtcm_rfc4115_n_max;
> > > > > >
> > > > > > +	/** Maximum number of MTR objects that can have their
> > meter
> > > > > configured
> > > > > > +	 * to run the srTCM packet per second algorithm. The value
> > > of 0
> > > > > > +	 * indicates this metering algorithm is not supported.
> > > > > > +	 * The maximum value is *n_max*.
> > > > > > +	 */
> > > > > > +	uint32_t meter_srtcm_pps_n_max;
> > > > > > +
> > > > > >   	/** Maximum traffic rate that can be metered by a
> single
> > > MTR
> > > > > object. For
> > > > > >   	 * srTCM RFC 2697, this is the maximum CIR rate. For
> trTCM
> > > RFC
> > > > > 2698,
> > > > > >   	 * this is the maximum PIR rate. For trTCM RFC 4115,
> this
> > > is the
> > > > > maximum
> > > > > > @@ -342,6 +364,12 @@ struct rte_mtr_capabilities {
> > > > > >   	 */
> > > > > >   	int color_aware_trtcm_rfc4115_supported;
> > > > > >
> > > > > > +	/**
> > > > > > +	 * When non-zero, it indicates that color aware mode is
> > > supported
> > > > > for
> > > > > > +	 * the srTCM packet per second  metering algorithm.
> > > >
> > > > No need for two spaces between the words second and metering.
> > > >
> > > > > > +	 */
> > > > > > +	int color_aware_srtcm_pps_supported;
> > > > > > +
> > > > > >   	/** When non-zero, it indicates that the policer
> packet
> > > recolor
> > > > > actions
> > > > > >   	 * are supported.
> > > > > >   	 * @see enum rte_mtr_policer_action
> > > > > >
> > > > >

Re: [dpdk-dev] [PATCH] [RFC, v2]: adds support PPS(packet per second) on meter

[Dumitrescu, Cristian]

> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Thursday, January 28, 2021 6:28 PM
> To: Li Zhang <lizh@nvidia.com>; dekelp@nvidia.com; orika@nvidia.com;
> viacheslavo@nvidia.com; matan@nvidia.com; Dumitrescu, Cristian
> <cristian.dumitrescu@intel.com>
> Cc: dev@dpdk.org; thomas@monjalon.net; rasland@nvidia.com
> Subject: Re: [dpdk-dev] [PATCH] [RFC, v2]: adds support PPS(packet per
> second) on meter
> 
> On 1/25/2021 1:20 AM, Li Zhang wrote:
> > Currently the flow Meter algorithms in rte_flow
> > only supports bytes per second(BPS).
> > Such as Single Rate Three Color Marker (srTCM rfc2697)
> > This RFC adds the packet per second definition in
> > Meter algorithms structure,
> > to support the rte_mtr APIs with type srTCM pps mode.
> > The below structure will be extended:
> > rte_mtr_algorithm
> > rte_mtr_meter_profile
> > Signed-off-by: Li Zhang <lizh@nvidia.com>
> 
> cc'ed Cristian for review/comment.
> 
> > ---
> >   lib/librte_ethdev/rte_mtr.h | 28 ++++++++++++++++++++++++++++
> >   1 file changed, 28 insertions(+)
> >
> > diff --git a/lib/librte_ethdev/rte_mtr.h b/lib/librte_ethdev/rte_mtr.h
> > index 916a09c5c3..3e88904faf 100644
> > --- a/lib/librte_ethdev/rte_mtr.h
> > +++ b/lib/librte_ethdev/rte_mtr.h
> > @@ -119,6 +119,9 @@ enum rte_mtr_algorithm {
> >
> >   	/** Two Rate Three Color Marker (trTCM) - IETF RFC 4115. */
> >   	RTE_MTR_TRTCM_RFC4115,
> > +
> > +	/** Single Rate Three Color Marker (srTCM) in Packet per second
> mode */
> > +	RTE_MTR_SRTCM_PPS,
> >   };
> >
> >   /**
> > @@ -171,6 +174,18 @@ struct rte_mtr_meter_profile {
> >   			/** Excess Burst Size (EBS) (bytes). */
> >   			uint64_t ebs;
> >   		} trtcm_rfc4115;
> > +
> > +		/** Items only valid when *alg* is set to srTCM - PPS. */
> > +		struct {
> > +			/** Committed Information Rate
> (CIR)(packets/second). */
> > +			uint64_t cir;
> > +
> > +			/** Committed Burst Size (CBS) (bytes). */
> > +			uint64_t cbs;
> > +
> > +			/** Excess Burst Size (EBS) (bytes). */
> > +			uint64_t ebs;
> > +		} srtcm_pps;
> >   	};
> >   };
> >
> > @@ -317,6 +332,13 @@ struct rte_mtr_capabilities {
> >   	 */
> >   	uint32_t meter_trtcm_rfc4115_n_max;
> >
> > +	/** Maximum number of MTR objects that can have their meter
> configured
> > +	 * to run the srTCM packet per second algorithm. The value of 0
> > +	 * indicates this metering algorithm is not supported.
> > +	 * The maximum value is *n_max*.
> > +	 */
> > +	uint32_t meter_srtcm_pps_n_max;
> > +
> >   	/** Maximum traffic rate that can be metered by a single MTR
> object. For
> >   	 * srTCM RFC 2697, this is the maximum CIR rate. For trTCM RFC 2698,
> >   	 * this is the maximum PIR rate. For trTCM RFC 4115, this is the
> maximum
> > @@ -342,6 +364,12 @@ struct rte_mtr_capabilities {
> >   	 */
> >   	int color_aware_trtcm_rfc4115_supported;
> >
> > +	/**
> > +	 * When non-zero, it indicates that color aware mode is supported
> for
> > +	 * the srTCM packet per second  metering algorithm.
> > +	 */
> > +	int color_aware_srtcm_pps_supported;
> > +
> >   	/** When non-zero, it indicates that the policer packet recolor
> actions
> >   	 * are supported.
> >   	 * @see enum rte_mtr_policer_action
> >

Hi Li,

Sorry for my delay.

We had this same problem earlier for the rte_tm.h API, where people asked to add support for WRED and shaper rates specified in packets to the existing byte rate support. I am more than happy to support adding the same here, but please let's adopt the same solution here rather than invent a different approach.

Please refer to struct rte_tm_wred_params and struct rte_tm_shaper_params from rte_tm.h: the packets vs. bytes mode is explicitly specified through the use of a flag called packet_mode that is added to the WRED and shaper profile. When packet_mode is 0, the profile rates and bucket sizes are specified in bytes per second and bytes, respectivelly; when packet_mode is not 0, the profile rates and bucket sizes are specified in packets and packets per second, respectivelly. The same profile parameters are used, no need to invent additional algorithms (such as srTCM - packet mode) or profile data structures. Can we do the same here, please?

This is a quick summary of the required API changes to add support for the packet mode, they are minimal:
a) Introduce the packet_mode flag in the profile parameters data structure.
b) Change the description (comment) of the rate and bucket size parameters in the meter profile parameters data structures to reflect that their values represents either bytes or packets, depending on the value of the new flag packet_mode from the same structure.
c) Add the relevant capabilities: just search for "packet" in the rte_tm.h capabilities data structures and apply the same to the rte_mtr.h capabilities, when applicable.

Regards,
Cristian

[dpdk-dev] [RFC v3 0/4] adds support PPS(packet per second) on meter

[Li Zhang]

v2:
* Rebase


Li Zhang (4):
  ethdev: add meter PPS profile
  common/mlx5: add meter mode definition in PRM file
  net/mlx5: support meter PPS profile
  app/testpmd: add meter pps mode cmd

 app/test-pmd/cmdline.c                        |   4 +
 app/test-pmd/cmdline_mtr.c                    | 105 ++++++++++++++++++
 app/test-pmd/cmdline_mtr.h                    |   1 +
 doc/guides/nics/mlx5.rst                      |   1 +
 .../traffic_metering_and_policing.rst         |   3 +-
 doc/guides/rel_notes/release_20_11.rst        |   5 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst   |  15 +++
 drivers/common/mlx5/mlx5_prm.h                |   8 ++
 drivers/net/mlx5/mlx5.h                       |  13 ++-
 drivers/net/mlx5/mlx5_flow_aso.c              |  17 ++-
 drivers/net/mlx5/mlx5_flow_meter.c            |  71 +++++++++---
 lib/librte_ethdev/rte_mtr.h                   |  32 ++++++
 12 files changed, 251 insertions(+), 24 deletions(-)

-- 
2.21.0

[dpdk-dev] [RFC v3 1/4] ethdev: add meter PPS profile

[Li Zhang]

Currently meter algorithms only supports rate is bytes per second(BPS).
Add this new meter srTCMp algorithm to support rate is packet per second.
So that it can meter traffic by packet per second.
The below structure will be extended:
rte_mtr_algorithm
rte_mtr_meter_profile
Signed-off-by: Li Zhang <lizh@nvidia.com>
---
 .../traffic_metering_and_policing.rst         |  3 +-
 doc/guides/rel_notes/release_20_11.rst        |  5 +++
 lib/librte_ethdev/rte_mtr.h                   | 32 +++++++++++++++++++
 3 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/doc/guides/prog_guide/traffic_metering_and_policing.rst b/doc/guides/prog_guide/traffic_metering_and_policing.rst
index 90c781eb1d..4d2405d44a 100644
--- a/doc/guides/prog_guide/traffic_metering_and_policing.rst
+++ b/doc/guides/prog_guide/traffic_metering_and_policing.rst
@@ -17,7 +17,8 @@ The main features are:
 * Part of DPDK rte_ethdev API
 * Capability query API
 * Metering algorithms: RFC 2697 Single Rate Three Color Marker (srTCM), RFC 2698
-  and RFC 4115 Two Rate Three Color Marker (trTCM)
+  and RFC 4115 Two Rate Three Color Marker (trTCM),
+  Single Rate Three Color Marker, Packet based (srTCMp).
 * Policer actions (per meter output color): recolor, drop
 * Statistics (per policer output color)
 
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index 7405a9864f..de04886cc9 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -429,6 +429,11 @@ New Features
   can leverage IOAT DMA channels with vhost asynchronous APIs.
   See the :doc:`../sample_app_ug/vhost` for more details.
 
+* **Added support for meter PPS profile.**
+
+  Currently meter algorithms only supports bytes per second(BPS).
+  Add this new meter algorithm to support packet per second (PPS) mode.
+  So that it can meter traffic by packet per second.
 
 Removed Items
 -------------
diff --git a/lib/librte_ethdev/rte_mtr.h b/lib/librte_ethdev/rte_mtr.h
index 916a09c5c3..f27a4b5354 100644
--- a/lib/librte_ethdev/rte_mtr.h
+++ b/lib/librte_ethdev/rte_mtr.h
@@ -119,6 +119,11 @@ enum rte_mtr_algorithm {
 
 	/** Two Rate Three Color Marker (trTCM) - IETF RFC 4115. */
 	RTE_MTR_TRTCM_RFC4115,
+
+	/** Single Rate Three Color Marker, Packet based (srTCMp).
+	 * - - similar to IETF RFC 2697 but rate is packet per second.
+	 */
+	RTE_MTR_SRTCMP,
 };
 
 /**
@@ -171,6 +176,20 @@ struct rte_mtr_meter_profile {
 			/** Excess Burst Size (EBS) (bytes). */
 			uint64_t ebs;
 		} trtcm_rfc4115;
+
+		/** Items only valid when *alg* is set to srTCMp. */
+		struct {
+			/** Committed Information Rate (CIR)
+			 * (packets/second).
+			 */
+			uint64_t cir;
+
+			/** Committed Burst Size (CBS) (packets). */
+			uint64_t cbs;
+
+			/** Excess Burst Size (EBS) (packets). */
+			uint64_t ebs;
+		} srtcmp;
 	};
 };
 
@@ -317,6 +336,13 @@ struct rte_mtr_capabilities {
 	 */
 	uint32_t meter_trtcm_rfc4115_n_max;
 
+	/** Maximum number of MTR objects that can have their meter configured
+	 * to run the srTCMp algorithm. The value of 0
+	 * indicates this metering algorithm is not supported.
+	 * The maximum value is *n_max*.
+	 */
+	uint32_t meter_srtcmp_n_max;
+
 	/** Maximum traffic rate that can be metered by a single MTR object. For
 	 * srTCM RFC 2697, this is the maximum CIR rate. For trTCM RFC 2698,
 	 * this is the maximum PIR rate. For trTCM RFC 4115, this is the maximum
@@ -342,6 +368,12 @@ struct rte_mtr_capabilities {
 	 */
 	int color_aware_trtcm_rfc4115_supported;
 
+	/**
+	 * When non-zero, it indicates that color aware mode is supported for
+	 * the srTCMp metering algorithm.
+	 */
+	int color_aware_srtcmp_supported;
+
 	/** When non-zero, it indicates that the policer packet recolor actions
 	 * are supported.
 	 * @see enum rte_mtr_policer_action
-- 
2.21.0

[dpdk-dev] [RFC v3 2/4] common/mlx5: add meter mode definition in PRM file

[Li Zhang]

Add meter mode definition in PRM file

Signed-off-by: Li Zhang <lizh@nvidia.com>
---
 drivers/common/mlx5/mlx5_prm.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/common/mlx5/mlx5_prm.h b/drivers/common/mlx5/mlx5_prm.h
index e3d4120849..609b1c3951 100644
--- a/drivers/common/mlx5/mlx5_prm.h
+++ b/drivers/common/mlx5/mlx5_prm.h
@@ -2177,6 +2177,13 @@ struct mlx5_ifc_flow_meter_parameters_bits {
 #define MLX5_IFC_FLOW_METER_PARAM_MASK UINT64_C(0x80FFFFFF)
 #define MLX5_IFC_FLOW_METER_DISABLE_CBS_CIR_VAL 0x14BF00C8
 
+enum {
+	MLX5_METER_MODE_IP_LEN = 0x0,
+	MLX5_METER_MODE_L2_LEN = 0x1,
+	MLX5_METER_MODE_L2_IPG_LEN = 0x2,
+	MLX5_METER_MODE_PKT = 0x3,
+};
+
 enum {
 	MLX5_CQE_SIZE_64B = 0x0,
 	MLX5_CQE_SIZE_128B = 0x1,
@@ -2508,6 +2515,7 @@ struct mlx5_aso_mtr_dseg {
 #define ASO_DSEG_VALID_OFFSET 31
 #define ASO_DSEG_BO_OFFSET 30
 #define ASO_DSEG_SC_OFFSET 28
+#define ASO_DSEG_MTR_MODE 24
 #define ASO_DSEG_CBS_EXP_OFFSET 24
 #define ASO_DSEG_CBS_MAN_OFFSET 16
 #define ASO_DSEG_CIR_EXP_MASK 0x1F
-- 
2.21.0

[dpdk-dev] [RFC v3 3/4] net/mlx5: support meter PPS profile

[Li Zhang]

Currently meter algorithms only supports bytes per second(BPS).
Such as Single Rate Three Color Marker (srTCM rfc2697)
Add this new meter srTCMp algorithm to support rate is packet per second.
So that it can meter traffic by packet per second (PPS).

Signed-off-by: Li Zhang <lizh@nvidia.com>
---
 doc/guides/nics/mlx5.rst           |  1 +
 drivers/net/mlx5/mlx5.h            | 13 ++++--
 drivers/net/mlx5/mlx5_flow_aso.c   | 17 ++++---
 drivers/net/mlx5/mlx5_flow_meter.c | 71 ++++++++++++++++++++++++------
 4 files changed, 79 insertions(+), 23 deletions(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index a390a4b53c..93f5c0e4d4 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -362,6 +362,7 @@ Limitations
   - Green color is not supported with drop action.
   - Yellow detection is not supported.
   - Red color must be with drop action.
+  - meter srTCMp algorithm is supported.
 
 Statistics
 ----------
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index 2790995dcc..16fa1b6c4d 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -742,8 +742,13 @@ struct mlx5_flow_meter_info {
 	/**< Flow meter action. */
 };
 
-/* RFC2697 parameter structure. */
-struct mlx5_flow_meter_srtcm_rfc2697_prm {
+/* PPS(packets per second) map to BPS(Bytes per second).
+ * HW treat packet as 128bytes in PPS mode
+ */
+#define MLX5_MTRS_PPS_MAP_BPS_SHIFT 7
+
+/* RFC2697/PPS parameter structure. */
+struct mlx5_flow_meter_srtcm_prm {
 	rte_be32_t cbs_cir;
 	/*
 	 * bit 24-28: cbs_exponent, bit 16-23 cbs_mantissa,
@@ -763,8 +768,8 @@ struct mlx5_flow_meter_profile {
 	uint32_t id; /**< Profile id. */
 	struct rte_mtr_meter_profile profile; /**< Profile detail. */
 	union {
-		struct mlx5_flow_meter_srtcm_rfc2697_prm srtcm_prm;
-		/**< srtcm_rfc2697 struct. */
+		struct mlx5_flow_meter_srtcm_prm srtcm_prm;
+		/**< srtcm_rfc2697/srtcm_pps struct. */
 	};
 	uint32_t ref_cnt; /**< Use count. */
 };
diff --git a/drivers/net/mlx5/mlx5_flow_aso.c b/drivers/net/mlx5/mlx5_flow_aso.c
index c9280b1f9d..3f3ba7e8fa 100644
--- a/drivers/net/mlx5/mlx5_flow_aso.c
+++ b/drivers/net/mlx5/mlx5_flow_aso.c
@@ -244,7 +244,6 @@ mlx5_aso_mtr_init_sq(struct mlx5_aso_sq *sq)
 	volatile struct mlx5_aso_wqe *restrict wqe;
 	int i;
 	int size = 1 << sq->log_desc_n;
-	uint32_t idx;
 
 	/* All the next fields state should stay constant. */
 	for (i = 0, wqe = &sq->wqes[0]; i < size; ++i, ++wqe) {
@@ -257,11 +256,6 @@ mlx5_aso_mtr_init_sq(struct mlx5_aso_sq *sq)
 			 (BYTEWISE_64BYTE << ASO_CSEG_DATA_MASK_MODE_OFFSET));
 		wqe->general_cseg.flags = RTE_BE32(MLX5_COMP_ALWAYS <<
 							 MLX5_COMP_MODE_OFFSET);
-		for (idx = 0; idx < MLX5_ASO_METERS_PER_WQE;
-			idx++)
-			wqe->aso_dseg.mtrs[idx].v_bo_sc_bbog_mm =
-				RTE_BE32((1 << ASO_DSEG_VALID_OFFSET) |
-				(MLX5_FLOW_COLOR_GREEN << ASO_DSEG_SC_OFFSET));
 	}
 }
 
@@ -744,6 +738,7 @@ mlx5_aso_mtr_sq_enqueue_single(struct mlx5_aso_sq *sq,
 {
 	volatile struct mlx5_aso_wqe *wqe = NULL;
 	struct mlx5_flow_meter_info *fm = NULL;
+	struct mlx5_flow_meter_profile *fmp;
 	uint16_t size = 1 << sq->log_desc_n;
 	uint16_t mask = size - 1;
 	uint16_t res = size - (uint16_t)(sq->head - sq->tail);
@@ -781,6 +776,16 @@ mlx5_aso_mtr_sq_enqueue_single(struct mlx5_aso_sq *sq,
 			RTE_BE32(MLX5_IFC_FLOW_METER_DISABLE_CBS_CIR_VAL);
 		wqe->aso_dseg.mtrs[dseg_idx].ebs_eir = 0;
 	}
+	fmp = fm->profile;
+	if (fmp->profile.alg == RTE_MTR_SRTCMP)
+		wqe->aso_dseg.mtrs[dseg_idx].v_bo_sc_bbog_mm =
+				RTE_BE32((1 << ASO_DSEG_VALID_OFFSET) |
+				(MLX5_FLOW_COLOR_GREEN << ASO_DSEG_SC_OFFSET) |
+				(MLX5_METER_MODE_PKT << ASO_DSEG_MTR_MODE));
+	else
+		wqe->aso_dseg.mtrs[dseg_idx].v_bo_sc_bbog_mm =
+				RTE_BE32((1 << ASO_DSEG_VALID_OFFSET) |
+				(MLX5_FLOW_COLOR_GREEN << ASO_DSEG_SC_OFFSET));
 	sq->head++;
 	sq->pi += 2;/* Each WQE contains 2 WQEBB's. */
 	rte_io_wmb();
diff --git a/drivers/net/mlx5/mlx5_flow_meter.c b/drivers/net/mlx5/mlx5_flow_meter.c
index 49f6229ae6..cf2fe8c173 100644
--- a/drivers/net/mlx5/mlx5_flow_meter.c
+++ b/drivers/net/mlx5/mlx5_flow_meter.c
@@ -33,7 +33,7 @@ mlx5_flow_meter_action_create(struct mlx5_priv *priv,
 #ifdef HAVE_MLX5_DR_CREATE_ACTION_FLOW_METER
 	struct mlx5dv_dr_flow_meter_attr mtr_init;
 	uint32_t fmp[MLX5_ST_SZ_DW(flow_meter_parameters)];
-	struct mlx5_flow_meter_srtcm_rfc2697_prm *srtcm =
+	struct mlx5_flow_meter_srtcm_prm *srtcm =
 						     &fm->profile->srtcm_prm;
 	uint32_t cbs_cir = rte_be_to_cpu_32(srtcm->cbs_cir);
 	uint32_t ebs_eir = rte_be_to_cpu_32(srtcm->ebs_eir);
@@ -157,6 +157,32 @@ mlx5_flow_meter_profile_validate(struct rte_eth_dev *dev,
 					      "Invalid metering parameters.");
 		}
 	}
+	if (priv->sh->meter_aso_en &&
+		profile->alg == RTE_MTR_SRTCMP) {
+		if (priv->config.hca_attr.qos.srtcm_sup) {
+			/* Verify support for flow meter parameters. */
+			if (profile->srtcmp.cir > 0 &&
+			    (profile->srtcmp.cir <<
+					MLX5_MTRS_PPS_MAP_BPS_SHIFT)
+						<= MLX5_SRTCM_CIR_MAX &&
+			    profile->srtcmp.cbs > 0 &&
+			    (profile->srtcmp.cbs <<
+					MLX5_MTRS_PPS_MAP_BPS_SHIFT)
+						<= MLX5_SRTCM_CBS_MAX &&
+			    (profile->srtcmp.ebs <<
+					MLX5_MTRS_PPS_MAP_BPS_SHIFT)
+						<= MLX5_SRTCM_EBS_MAX)
+				return 0;
+			else
+				return -rte_mtr_error_set
+					     (error, ENOTSUP,
+					      RTE_MTR_ERROR_TYPE_MTR_PARAMS,
+					      NULL,
+					      profile->srtcmp.ebs ?
+					      "Metering value ebs must be 0." :
+					      "Invalid metering parameters.");
+		}
+	}
 	return -rte_mtr_error_set(error, ENOTSUP,
 				  RTE_MTR_ERROR_TYPE_METER_PROFILE,
 				  NULL, "Metering algorithm not supported.");
@@ -238,19 +264,35 @@ 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 rte_mtr_error *error)
+			struct mlx5_priv *priv, struct rte_mtr_error *error)
 {
-	struct mlx5_flow_meter_srtcm_rfc2697_prm *srtcm = &fmp->srtcm_prm;
+	struct mlx5_flow_meter_srtcm_prm *srtcm = &fmp->srtcm_prm;
 	uint8_t man, exp;
 	uint32_t cbs_exp, cbs_man, cir_exp, cir_man;
 	uint32_t ebs_exp, ebs_man;
+	uint64_t cir, cbs, ebs;
 
-	if (fmp->profile.alg != RTE_MTR_SRTCM_RFC2697)
-		return -rte_mtr_error_set(error, ENOTSUP,
+	if (fmp->profile.alg == RTE_MTR_SRTCM_RFC2697) {
+		cir = fmp->profile.srtcm_rfc2697.cir;
+		cbs = fmp->profile.srtcm_rfc2697.cbs;
+		ebs = fmp->profile.srtcm_rfc2697.ebs;
+	} else {
+		if (priv->sh->meter_aso_en &&
+			fmp->profile.alg == RTE_MTR_SRTCMP) {
+			cir = fmp->profile.srtcmp.cir <<
+				MLX5_MTRS_PPS_MAP_BPS_SHIFT;
+			cbs = fmp->profile.srtcmp.cbs <<
+				MLX5_MTRS_PPS_MAP_BPS_SHIFT;
+			ebs = fmp->profile.srtcmp.ebs <<
+				MLX5_MTRS_PPS_MAP_BPS_SHIFT;
+		} else {
+			return -rte_mtr_error_set(error, ENOTSUP,
 				RTE_MTR_ERROR_TYPE_METER_PROFILE,
 				NULL, "Metering algorithm not supported.");
+		}
+	}
 	/* cir = 8G * cir_mantissa * 1/(2^cir_exponent)) Bytes/Sec */
-	mlx5_flow_meter_cir_man_exp_calc(fmp->profile.srtcm_rfc2697.cir,
+	mlx5_flow_meter_cir_man_exp_calc(cir,
 				    &man, &exp);
 	/* Check if cir mantissa is too large. */
 	if (exp > ASO_DSEG_CIR_EXP_MASK)
@@ -261,7 +303,7 @@ mlx5_flow_meter_param_fill(struct mlx5_flow_meter_profile *fmp,
 	cir_man = man;
 	cir_exp = exp;
 	 /* cbs = cbs_mantissa * 2^cbs_exponent */
-	mlx5_flow_meter_xbs_man_exp_calc(fmp->profile.srtcm_rfc2697.cbs,
+	mlx5_flow_meter_xbs_man_exp_calc(cbs,
 				    &man, &exp);
 	/* Check if cbs mantissa is too large. */
 	if (exp > ASO_DSEG_EXP_MASK)
@@ -275,7 +317,7 @@ mlx5_flow_meter_param_fill(struct mlx5_flow_meter_profile *fmp,
 				cbs_man << ASO_DSEG_CBS_MAN_OFFSET |
 				cir_exp << ASO_DSEG_CIR_EXP_OFFSET |
 				cir_man);
-	mlx5_flow_meter_xbs_man_exp_calc(fmp->profile.srtcm_rfc2697.ebs,
+	mlx5_flow_meter_xbs_man_exp_calc(ebs,
 				    &man, &exp);
 	/* Check if ebs mantissa is too large. */
 	if (exp > ASO_DSEG_EXP_MASK)
@@ -316,11 +358,14 @@ mlx5_flow_mtr_cap_get(struct rte_eth_dev *dev,
 					  RTE_MTR_ERROR_TYPE_UNSPECIFIED, NULL,
 					  "Meter is not supported");
 	memset(cap, 0, sizeof(*cap));
-	if (priv->sh->meter_aso_en)
+	if (priv->sh->meter_aso_en) {
 	    /* 2 meters per one ASO cache line. */
 		cap->n_max = 1 << (qattr->log_max_num_meter_aso + 1);
-	else
+		cap->meter_srtcmp_n_max = qattr->srtcm_sup ? cap->n_max : 0;
+	} else {
 		cap->n_max = 1 << qattr->log_max_flow_meter;
+		cap->meter_srtcmp_n_max = 0;
+	}
 	cap->n_shared_max = cap->n_max;
 	cap->identical = 1;
 	cap->shared_identical = 1;
@@ -382,7 +427,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, error);
+	ret = mlx5_flow_meter_param_fill(fmp, priv, error);
 	if (ret)
 		goto error;
 	/* Add to list. */
@@ -539,7 +584,7 @@ mlx5_flow_meter_validate(struct mlx5_priv *priv, uint32_t meter_id,
 static int
 mlx5_flow_meter_action_modify(struct mlx5_priv *priv,
 		struct mlx5_flow_meter_info *fm,
-		const struct mlx5_flow_meter_srtcm_rfc2697_prm *srtcm,
+		const struct mlx5_flow_meter_srtcm_prm *srtcm,
 		uint64_t modify_bits, uint32_t active_state, uint32_t is_enable)
 {
 #ifdef HAVE_MLX5_DR_CREATE_ACTION_FLOW_METER
@@ -899,7 +944,7 @@ mlx5_flow_meter_modify_state(struct mlx5_priv *priv,
 			     uint32_t new_state,
 			     struct rte_mtr_error *error)
 {
-	static const struct mlx5_flow_meter_srtcm_rfc2697_prm srtcm = {
+	static const struct mlx5_flow_meter_srtcm_prm srtcm = {
 		.cbs_cir = RTE_BE32(MLX5_IFC_FLOW_METER_DISABLE_CBS_CIR_VAL),
 		.ebs_eir = 0,
 	};
-- 
2.21.0

[dpdk-dev] [RFC v3 4/4] app/testpmd: add meter pps mode cmd

[Li Zhang]

Support meter pps mode

Signed-off-by: Li Zhang <lizh@nvidia.com>
---
 app/test-pmd/cmdline.c                      |   4 +
 app/test-pmd/cmdline_mtr.c                  | 105 ++++++++++++++++++++
 app/test-pmd/cmdline_mtr.h                  |   1 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  15 +++
 4 files changed, 125 insertions(+)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index d274a7cb8c..1a3fc644dc 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -698,6 +698,9 @@ static void cmd_help_long_parsed(void *parsed_result,
 			"add port meter profile trtcm_rfc4115 (port_id) (profile_id) (cir) (eir) (cbs) (ebs)\n"
 			"    meter profile add - trtcm rfc 4115\n\n"
 
+			"add port meter profile srtcmp (port_id) (profile_id) (cipr) (cpbs) (epbs)\n"
+			"    meter profile add - srtcmp packet per second\n\n"
+
 			"del port meter profile (port_id) (profile_id)\n"
 			"    meter profile delete\n\n"
 
@@ -17006,6 +17009,7 @@ cmdline_parse_ctx_t main_ctx[] = {
 	(cmdline_parse_inst_t *)&cmd_show_port_meter_cap,
 	(cmdline_parse_inst_t *)&cmd_add_port_meter_profile_srtcm,
 	(cmdline_parse_inst_t *)&cmd_add_port_meter_profile_trtcm,
+	(cmdline_parse_inst_t *)&cmd_add_port_meter_profile_srtcmp,
 	(cmdline_parse_inst_t *)&cmd_del_port_meter_profile,
 	(cmdline_parse_inst_t *)&cmd_create_port_meter,
 	(cmdline_parse_inst_t *)&cmd_enable_port_meter,
diff --git a/app/test-pmd/cmdline_mtr.c b/app/test-pmd/cmdline_mtr.c
index 399ee56e07..3f62240a0d 100644
--- a/app/test-pmd/cmdline_mtr.c
+++ b/app/test-pmd/cmdline_mtr.c
@@ -295,6 +295,8 @@ static void cmd_show_port_meter_cap_parsed(void *parsed_result,
 		cap.meter_trtcm_rfc2698_n_max);
 	printf("cap.meter_trtcm_rfc4115_n_max %" PRIu32 "\n",
 		cap.meter_trtcm_rfc4115_n_max);
+	printf("cap.meter_srtcmp_n_max %" PRIu32 "\n",
+		cap.meter_srtcmp_n_max);
 	printf("cap.meter_rate_max %" PRIu64 "\n", cap.meter_rate_max);
 	printf("cap.color_aware_srtcm_rfc2697_supported %" PRId32 "\n",
 		cap.color_aware_srtcm_rfc2697_supported);
@@ -302,6 +304,8 @@ static void cmd_show_port_meter_cap_parsed(void *parsed_result,
 		cap.color_aware_trtcm_rfc2698_supported);
 	printf("cap.color_aware_trtcm_rfc4115_supported %" PRId32 "\n",
 		cap.color_aware_trtcm_rfc4115_supported);
+	printf("cap.color_aware_srtcmp_supported %" PRId32 "\n",
+		cap.color_aware_srtcmp_supported);
 	printf("cap.policer_action_recolor_supported %" PRId32 "\n",
 		cap.policer_action_recolor_supported);
 	printf("cap.policer_action_drop_supported %" PRId32 "\n",
@@ -644,6 +648,107 @@ cmdline_parse_inst_t cmd_add_port_meter_profile_trtcm_rfc4115 = {
 	},
 };
 
+/* *** Add Port Meter Profile srtcmp *** */
+struct cmd_add_port_meter_profile_srtcmp_result {
+	cmdline_fixed_string_t add;
+	cmdline_fixed_string_t port;
+	cmdline_fixed_string_t meter;
+	cmdline_fixed_string_t profile;
+	cmdline_fixed_string_t srtcmp;
+	uint16_t port_id;
+	uint32_t profile_id;
+	uint64_t cir;
+	uint64_t cbs;
+	uint64_t ebs;
+};
+
+cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcmp_add =
+	TOKEN_STRING_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result, add, "add");
+cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcmp_port =
+	TOKEN_STRING_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			port, "port");
+cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcmp_meter =
+	TOKEN_STRING_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			meter, "meter");
+cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcmp_profile =
+	TOKEN_STRING_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			profile, "profile");
+cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcmp_srtcmp =
+	TOKEN_STRING_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			srtcmp, "srtcmp");
+cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcmp_port_id =
+	TOKEN_NUM_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			port_id, RTE_UINT16);
+cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcmp_profile_id =
+	TOKEN_NUM_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			profile_id, RTE_UINT32);
+cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcmp_cir =
+	TOKEN_NUM_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			cir, RTE_UINT64);
+cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcmp_cbs =
+	TOKEN_NUM_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			cbs, RTE_UINT64);
+cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcmp_ebs =
+	TOKEN_NUM_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			ebs, RTE_UINT64);
+
+static void cmd_add_port_meter_profile_srtcmp_parsed(void *parsed_result,
+	__rte_unused struct cmdline *cl,
+	__rte_unused void *data)
+{
+	struct cmd_add_port_meter_profile_srtcmp_result *res = parsed_result;
+	struct rte_mtr_meter_profile mp;
+	struct rte_mtr_error error;
+	uint32_t profile_id = res->profile_id;
+	uint16_t port_id = res->port_id;
+	int ret;
+
+	if (port_id_is_invalid(port_id, ENABLED_WARN))
+		return;
+
+	/* Private shaper profile params */
+	memset(&mp, 0, sizeof(struct rte_mtr_meter_profile));
+	mp.alg = RTE_MTR_SRTCMP;
+	mp.srtcmp.cir = res->cir;
+	mp.srtcmp.cbs = res->cbs;
+	mp.srtcmp.ebs = res->ebs;
+
+	ret = rte_mtr_meter_profile_add(port_id, profile_id, &mp, &error);
+	if (ret != 0) {
+		print_err_msg(&error);
+		return;
+	}
+}
+
+cmdline_parse_inst_t cmd_add_port_meter_profile_srtcmp = {
+	.f = cmd_add_port_meter_profile_srtcmp_parsed,
+	.data = NULL,
+	.help_str = "Add port meter profile srtcmp",
+	.tokens = {
+		(void *)&cmd_add_port_meter_profile_srtcmp_add,
+		(void *)&cmd_add_port_meter_profile_srtcmp_port,
+		(void *)&cmd_add_port_meter_profile_srtcmp_meter,
+		(void *)&cmd_add_port_meter_profile_srtcmp_profile,
+		(void *)&cmd_add_port_meter_profile_srtcmp_srtcmp,
+		(void *)&cmd_add_port_meter_profile_srtcmp_port_id,
+		(void *)&cmd_add_port_meter_profile_srtcmp_profile_id,
+		(void *)&cmd_add_port_meter_profile_srtcmp_cir,
+		(void *)&cmd_add_port_meter_profile_srtcmp_cbs,
+		(void *)&cmd_add_port_meter_profile_srtcmp_ebs,
+		NULL,
+	},
+};
+
 /* *** Delete Port Meter Profile *** */
 struct cmd_del_port_meter_profile_result {
 	cmdline_fixed_string_t del;
diff --git a/app/test-pmd/cmdline_mtr.h b/app/test-pmd/cmdline_mtr.h
index e69d6da023..01ef85e1e7 100644
--- a/app/test-pmd/cmdline_mtr.h
+++ b/app/test-pmd/cmdline_mtr.h
@@ -10,6 +10,7 @@ extern cmdline_parse_inst_t cmd_show_port_meter_cap;
 extern cmdline_parse_inst_t cmd_add_port_meter_profile_srtcm;
 extern cmdline_parse_inst_t cmd_add_port_meter_profile_trtcm;
 extern cmdline_parse_inst_t cmd_add_port_meter_profile_trtcm_rfc4115;
+extern cmdline_parse_inst_t cmd_add_port_meter_profile_srtcmp;
 extern cmdline_parse_inst_t cmd_del_port_meter_profile;
 extern cmdline_parse_inst_t cmd_create_port_meter;
 extern cmdline_parse_inst_t cmd_enable_port_meter;
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 37278d31d6..d11de05583 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -2734,6 +2734,21 @@ where:
 * ``cbs``: Committed burst size (bytes).
 * ``ebs``: Excess burst size (bytes).
 
+add port meter profile (srTcmp)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Add meter profile (srTcmp) to the ethernet device::
+
+   testpmd> add port meter profile srtcmp (port_id) (profile_id) \
+   (cir) (cbs) (ebs)
+
+where:
+
+* ``profile_id``: ID for the meter profile.
+* ``cpr``: Committed Information Rate (CIR) (packets/second).
+* ``cbs``: Committed Burst Size (CBS) (packets).
+* ``ebs``: Excess Burst Size (EBS) (packets).
+
 delete port meter profile
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
-- 
2.21.0

[dpdk-dev] [RFC v3 0/4] adds support PPS(packet per second) on meter

[Li Zhang]

v2:
* Rebase


Li Zhang (4):
  ethdev: add meter PPS profile
  common/mlx5: add meter mode definition in PRM file
  net/mlx5: support meter PPS profile
  app/testpmd: add meter pps mode cmd

 app/test-pmd/cmdline.c                        |   4 +
 app/test-pmd/cmdline_mtr.c                    | 105 ++++++++++++++++++
 app/test-pmd/cmdline_mtr.h                    |   1 +
 doc/guides/nics/mlx5.rst                      |   1 +
 .../traffic_metering_and_policing.rst         |   3 +-
 doc/guides/rel_notes/release_20_11.rst        |   5 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst   |  15 +++
 drivers/common/mlx5/mlx5_prm.h                |   8 ++
 drivers/net/mlx5/mlx5.h                       |  13 ++-
 drivers/net/mlx5/mlx5_flow_aso.c              |  17 ++-
 drivers/net/mlx5/mlx5_flow_meter.c            |  71 +++++++++---
 lib/librte_ethdev/rte_mtr.h                   |  32 ++++++
 12 files changed, 251 insertions(+), 24 deletions(-)

-- 
2.21.0

[dpdk-dev] [RFC v3 1/4] ethdev: add meter PPS profile

[Li Zhang]

Currently meter algorithms only supports rate is bytes per second(BPS).
Add this new meter srTCMp algorithm to support rate is packet per second.
So that it can meter traffic by packet per second.
The below structure will be extended:
rte_mtr_algorithm
rte_mtr_meter_profile
Signed-off-by: Li Zhang <lizh@nvidia.com>
---
 .../traffic_metering_and_policing.rst         |  3 +-
 doc/guides/rel_notes/release_20_11.rst        |  5 +++
 lib/librte_ethdev/rte_mtr.h                   | 32 +++++++++++++++++++
 3 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/doc/guides/prog_guide/traffic_metering_and_policing.rst b/doc/guides/prog_guide/traffic_metering_and_policing.rst
index 90c781eb1d..4d2405d44a 100644
--- a/doc/guides/prog_guide/traffic_metering_and_policing.rst
+++ b/doc/guides/prog_guide/traffic_metering_and_policing.rst
@@ -17,7 +17,8 @@ The main features are:
 * Part of DPDK rte_ethdev API
 * Capability query API
 * Metering algorithms: RFC 2697 Single Rate Three Color Marker (srTCM), RFC 2698
-  and RFC 4115 Two Rate Three Color Marker (trTCM)
+  and RFC 4115 Two Rate Three Color Marker (trTCM),
+  Single Rate Three Color Marker, Packet based (srTCMp).
 * Policer actions (per meter output color): recolor, drop
 * Statistics (per policer output color)
 
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index 7405a9864f..de04886cc9 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -429,6 +429,11 @@ New Features
   can leverage IOAT DMA channels with vhost asynchronous APIs.
   See the :doc:`../sample_app_ug/vhost` for more details.
 
+* **Added support for meter PPS profile.**
+
+  Currently meter algorithms only supports bytes per second(BPS).
+  Add this new meter algorithm to support packet per second (PPS) mode.
+  So that it can meter traffic by packet per second.
 
 Removed Items
 -------------
diff --git a/lib/librte_ethdev/rte_mtr.h b/lib/librte_ethdev/rte_mtr.h
index 916a09c5c3..f27a4b5354 100644
--- a/lib/librte_ethdev/rte_mtr.h
+++ b/lib/librte_ethdev/rte_mtr.h
@@ -119,6 +119,11 @@ enum rte_mtr_algorithm {
 
 	/** Two Rate Three Color Marker (trTCM) - IETF RFC 4115. */
 	RTE_MTR_TRTCM_RFC4115,
+
+	/** Single Rate Three Color Marker, Packet based (srTCMp).
+	 * - - similar to IETF RFC 2697 but rate is packet per second.
+	 */
+	RTE_MTR_SRTCMP,
 };
 
 /**
@@ -171,6 +176,20 @@ struct rte_mtr_meter_profile {
 			/** Excess Burst Size (EBS) (bytes). */
 			uint64_t ebs;
 		} trtcm_rfc4115;
+
+		/** Items only valid when *alg* is set to srTCMp. */
+		struct {
+			/** Committed Information Rate (CIR)
+			 * (packets/second).
+			 */
+			uint64_t cir;
+
+			/** Committed Burst Size (CBS) (packets). */
+			uint64_t cbs;
+
+			/** Excess Burst Size (EBS) (packets). */
+			uint64_t ebs;
+		} srtcmp;
 	};
 };
 
@@ -317,6 +336,13 @@ struct rte_mtr_capabilities {
 	 */
 	uint32_t meter_trtcm_rfc4115_n_max;
 
+	/** Maximum number of MTR objects that can have their meter configured
+	 * to run the srTCMp algorithm. The value of 0
+	 * indicates this metering algorithm is not supported.
+	 * The maximum value is *n_max*.
+	 */
+	uint32_t meter_srtcmp_n_max;
+
 	/** Maximum traffic rate that can be metered by a single MTR object. For
 	 * srTCM RFC 2697, this is the maximum CIR rate. For trTCM RFC 2698,
 	 * this is the maximum PIR rate. For trTCM RFC 4115, this is the maximum
@@ -342,6 +368,12 @@ struct rte_mtr_capabilities {
 	 */
 	int color_aware_trtcm_rfc4115_supported;
 
+	/**
+	 * When non-zero, it indicates that color aware mode is supported for
+	 * the srTCMp metering algorithm.
+	 */
+	int color_aware_srtcmp_supported;
+
 	/** When non-zero, it indicates that the policer packet recolor actions
 	 * are supported.
 	 * @see enum rte_mtr_policer_action
-- 
2.21.0

[dpdk-dev] [RFC v3 2/4] common/mlx5: add meter mode definition in PRM file

[Li Zhang]

Add meter mode definition in PRM file

Signed-off-by: Li Zhang <lizh@nvidia.com>
---
 drivers/common/mlx5/mlx5_prm.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/common/mlx5/mlx5_prm.h b/drivers/common/mlx5/mlx5_prm.h
index e3d4120849..609b1c3951 100644
--- a/drivers/common/mlx5/mlx5_prm.h
+++ b/drivers/common/mlx5/mlx5_prm.h
@@ -2177,6 +2177,13 @@ struct mlx5_ifc_flow_meter_parameters_bits {
 #define MLX5_IFC_FLOW_METER_PARAM_MASK UINT64_C(0x80FFFFFF)
 #define MLX5_IFC_FLOW_METER_DISABLE_CBS_CIR_VAL 0x14BF00C8
 
+enum {
+	MLX5_METER_MODE_IP_LEN = 0x0,
+	MLX5_METER_MODE_L2_LEN = 0x1,
+	MLX5_METER_MODE_L2_IPG_LEN = 0x2,
+	MLX5_METER_MODE_PKT = 0x3,
+};
+
 enum {
 	MLX5_CQE_SIZE_64B = 0x0,
 	MLX5_CQE_SIZE_128B = 0x1,
@@ -2508,6 +2515,7 @@ struct mlx5_aso_mtr_dseg {
 #define ASO_DSEG_VALID_OFFSET 31
 #define ASO_DSEG_BO_OFFSET 30
 #define ASO_DSEG_SC_OFFSET 28
+#define ASO_DSEG_MTR_MODE 24
 #define ASO_DSEG_CBS_EXP_OFFSET 24
 #define ASO_DSEG_CBS_MAN_OFFSET 16
 #define ASO_DSEG_CIR_EXP_MASK 0x1F
-- 
2.21.0

[dpdk-dev] [RFC v3 3/4] net/mlx5: support meter PPS profile

[Li Zhang]

Currently meter algorithms only supports bytes per second(BPS).
Such as Single Rate Three Color Marker (srTCM rfc2697)
Add this new meter srTCMp algorithm to support rate is packet per second.
So that it can meter traffic by packet per second (PPS).

Signed-off-by: Li Zhang <lizh@nvidia.com>
---
 doc/guides/nics/mlx5.rst           |  1 +
 drivers/net/mlx5/mlx5.h            | 13 ++++--
 drivers/net/mlx5/mlx5_flow_aso.c   | 17 ++++---
 drivers/net/mlx5/mlx5_flow_meter.c | 71 ++++++++++++++++++++++++------
 4 files changed, 79 insertions(+), 23 deletions(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index a390a4b53c..93f5c0e4d4 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -362,6 +362,7 @@ Limitations
   - Green color is not supported with drop action.
   - Yellow detection is not supported.
   - Red color must be with drop action.
+  - meter srTCMp algorithm is supported.
 
 Statistics
 ----------
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index 2790995dcc..16fa1b6c4d 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -742,8 +742,13 @@ struct mlx5_flow_meter_info {
 	/**< Flow meter action. */
 };
 
-/* RFC2697 parameter structure. */
-struct mlx5_flow_meter_srtcm_rfc2697_prm {
+/* PPS(packets per second) map to BPS(Bytes per second).
+ * HW treat packet as 128bytes in PPS mode
+ */
+#define MLX5_MTRS_PPS_MAP_BPS_SHIFT 7
+
+/* RFC2697/PPS parameter structure. */
+struct mlx5_flow_meter_srtcm_prm {
 	rte_be32_t cbs_cir;
 	/*
 	 * bit 24-28: cbs_exponent, bit 16-23 cbs_mantissa,
@@ -763,8 +768,8 @@ struct mlx5_flow_meter_profile {
 	uint32_t id; /**< Profile id. */
 	struct rte_mtr_meter_profile profile; /**< Profile detail. */
 	union {
-		struct mlx5_flow_meter_srtcm_rfc2697_prm srtcm_prm;
-		/**< srtcm_rfc2697 struct. */
+		struct mlx5_flow_meter_srtcm_prm srtcm_prm;
+		/**< srtcm_rfc2697/srtcm_pps struct. */
 	};
 	uint32_t ref_cnt; /**< Use count. */
 };
diff --git a/drivers/net/mlx5/mlx5_flow_aso.c b/drivers/net/mlx5/mlx5_flow_aso.c
index c9280b1f9d..3f3ba7e8fa 100644
--- a/drivers/net/mlx5/mlx5_flow_aso.c
+++ b/drivers/net/mlx5/mlx5_flow_aso.c
@@ -244,7 +244,6 @@ mlx5_aso_mtr_init_sq(struct mlx5_aso_sq *sq)
 	volatile struct mlx5_aso_wqe *restrict wqe;
 	int i;
 	int size = 1 << sq->log_desc_n;
-	uint32_t idx;
 
 	/* All the next fields state should stay constant. */
 	for (i = 0, wqe = &sq->wqes[0]; i < size; ++i, ++wqe) {
@@ -257,11 +256,6 @@ mlx5_aso_mtr_init_sq(struct mlx5_aso_sq *sq)
 			 (BYTEWISE_64BYTE << ASO_CSEG_DATA_MASK_MODE_OFFSET));
 		wqe->general_cseg.flags = RTE_BE32(MLX5_COMP_ALWAYS <<
 							 MLX5_COMP_MODE_OFFSET);
-		for (idx = 0; idx < MLX5_ASO_METERS_PER_WQE;
-			idx++)
-			wqe->aso_dseg.mtrs[idx].v_bo_sc_bbog_mm =
-				RTE_BE32((1 << ASO_DSEG_VALID_OFFSET) |
-				(MLX5_FLOW_COLOR_GREEN << ASO_DSEG_SC_OFFSET));
 	}
 }
 
@@ -744,6 +738,7 @@ mlx5_aso_mtr_sq_enqueue_single(struct mlx5_aso_sq *sq,
 {
 	volatile struct mlx5_aso_wqe *wqe = NULL;
 	struct mlx5_flow_meter_info *fm = NULL;
+	struct mlx5_flow_meter_profile *fmp;
 	uint16_t size = 1 << sq->log_desc_n;
 	uint16_t mask = size - 1;
 	uint16_t res = size - (uint16_t)(sq->head - sq->tail);
@@ -781,6 +776,16 @@ mlx5_aso_mtr_sq_enqueue_single(struct mlx5_aso_sq *sq,
 			RTE_BE32(MLX5_IFC_FLOW_METER_DISABLE_CBS_CIR_VAL);
 		wqe->aso_dseg.mtrs[dseg_idx].ebs_eir = 0;
 	}
+	fmp = fm->profile;
+	if (fmp->profile.alg == RTE_MTR_SRTCMP)
+		wqe->aso_dseg.mtrs[dseg_idx].v_bo_sc_bbog_mm =
+				RTE_BE32((1 << ASO_DSEG_VALID_OFFSET) |
+				(MLX5_FLOW_COLOR_GREEN << ASO_DSEG_SC_OFFSET) |
+				(MLX5_METER_MODE_PKT << ASO_DSEG_MTR_MODE));
+	else
+		wqe->aso_dseg.mtrs[dseg_idx].v_bo_sc_bbog_mm =
+				RTE_BE32((1 << ASO_DSEG_VALID_OFFSET) |
+				(MLX5_FLOW_COLOR_GREEN << ASO_DSEG_SC_OFFSET));
 	sq->head++;
 	sq->pi += 2;/* Each WQE contains 2 WQEBB's. */
 	rte_io_wmb();
diff --git a/drivers/net/mlx5/mlx5_flow_meter.c b/drivers/net/mlx5/mlx5_flow_meter.c
index 49f6229ae6..cf2fe8c173 100644
--- a/drivers/net/mlx5/mlx5_flow_meter.c
+++ b/drivers/net/mlx5/mlx5_flow_meter.c
@@ -33,7 +33,7 @@ mlx5_flow_meter_action_create(struct mlx5_priv *priv,
 #ifdef HAVE_MLX5_DR_CREATE_ACTION_FLOW_METER
 	struct mlx5dv_dr_flow_meter_attr mtr_init;
 	uint32_t fmp[MLX5_ST_SZ_DW(flow_meter_parameters)];
-	struct mlx5_flow_meter_srtcm_rfc2697_prm *srtcm =
+	struct mlx5_flow_meter_srtcm_prm *srtcm =
 						     &fm->profile->srtcm_prm;
 	uint32_t cbs_cir = rte_be_to_cpu_32(srtcm->cbs_cir);
 	uint32_t ebs_eir = rte_be_to_cpu_32(srtcm->ebs_eir);
@@ -157,6 +157,32 @@ mlx5_flow_meter_profile_validate(struct rte_eth_dev *dev,
 					      "Invalid metering parameters.");
 		}
 	}
+	if (priv->sh->meter_aso_en &&
+		profile->alg == RTE_MTR_SRTCMP) {
+		if (priv->config.hca_attr.qos.srtcm_sup) {
+			/* Verify support for flow meter parameters. */
+			if (profile->srtcmp.cir > 0 &&
+			    (profile->srtcmp.cir <<
+					MLX5_MTRS_PPS_MAP_BPS_SHIFT)
+						<= MLX5_SRTCM_CIR_MAX &&
+			    profile->srtcmp.cbs > 0 &&
+			    (profile->srtcmp.cbs <<
+					MLX5_MTRS_PPS_MAP_BPS_SHIFT)
+						<= MLX5_SRTCM_CBS_MAX &&
+			    (profile->srtcmp.ebs <<
+					MLX5_MTRS_PPS_MAP_BPS_SHIFT)
+						<= MLX5_SRTCM_EBS_MAX)
+				return 0;
+			else
+				return -rte_mtr_error_set
+					     (error, ENOTSUP,
+					      RTE_MTR_ERROR_TYPE_MTR_PARAMS,
+					      NULL,
+					      profile->srtcmp.ebs ?
+					      "Metering value ebs must be 0." :
+					      "Invalid metering parameters.");
+		}
+	}
 	return -rte_mtr_error_set(error, ENOTSUP,
 				  RTE_MTR_ERROR_TYPE_METER_PROFILE,
 				  NULL, "Metering algorithm not supported.");
@@ -238,19 +264,35 @@ 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 rte_mtr_error *error)
+			struct mlx5_priv *priv, struct rte_mtr_error *error)
 {
-	struct mlx5_flow_meter_srtcm_rfc2697_prm *srtcm = &fmp->srtcm_prm;
+	struct mlx5_flow_meter_srtcm_prm *srtcm = &fmp->srtcm_prm;
 	uint8_t man, exp;
 	uint32_t cbs_exp, cbs_man, cir_exp, cir_man;
 	uint32_t ebs_exp, ebs_man;
+	uint64_t cir, cbs, ebs;
 
-	if (fmp->profile.alg != RTE_MTR_SRTCM_RFC2697)
-		return -rte_mtr_error_set(error, ENOTSUP,
+	if (fmp->profile.alg == RTE_MTR_SRTCM_RFC2697) {
+		cir = fmp->profile.srtcm_rfc2697.cir;
+		cbs = fmp->profile.srtcm_rfc2697.cbs;
+		ebs = fmp->profile.srtcm_rfc2697.ebs;
+	} else {
+		if (priv->sh->meter_aso_en &&
+			fmp->profile.alg == RTE_MTR_SRTCMP) {
+			cir = fmp->profile.srtcmp.cir <<
+				MLX5_MTRS_PPS_MAP_BPS_SHIFT;
+			cbs = fmp->profile.srtcmp.cbs <<
+				MLX5_MTRS_PPS_MAP_BPS_SHIFT;
+			ebs = fmp->profile.srtcmp.ebs <<
+				MLX5_MTRS_PPS_MAP_BPS_SHIFT;
+		} else {
+			return -rte_mtr_error_set(error, ENOTSUP,
 				RTE_MTR_ERROR_TYPE_METER_PROFILE,
 				NULL, "Metering algorithm not supported.");
+		}
+	}
 	/* cir = 8G * cir_mantissa * 1/(2^cir_exponent)) Bytes/Sec */
-	mlx5_flow_meter_cir_man_exp_calc(fmp->profile.srtcm_rfc2697.cir,
+	mlx5_flow_meter_cir_man_exp_calc(cir,
 				    &man, &exp);
 	/* Check if cir mantissa is too large. */
 	if (exp > ASO_DSEG_CIR_EXP_MASK)
@@ -261,7 +303,7 @@ mlx5_flow_meter_param_fill(struct mlx5_flow_meter_profile *fmp,
 	cir_man = man;
 	cir_exp = exp;
 	 /* cbs = cbs_mantissa * 2^cbs_exponent */
-	mlx5_flow_meter_xbs_man_exp_calc(fmp->profile.srtcm_rfc2697.cbs,
+	mlx5_flow_meter_xbs_man_exp_calc(cbs,
 				    &man, &exp);
 	/* Check if cbs mantissa is too large. */
 	if (exp > ASO_DSEG_EXP_MASK)
@@ -275,7 +317,7 @@ mlx5_flow_meter_param_fill(struct mlx5_flow_meter_profile *fmp,
 				cbs_man << ASO_DSEG_CBS_MAN_OFFSET |
 				cir_exp << ASO_DSEG_CIR_EXP_OFFSET |
 				cir_man);
-	mlx5_flow_meter_xbs_man_exp_calc(fmp->profile.srtcm_rfc2697.ebs,
+	mlx5_flow_meter_xbs_man_exp_calc(ebs,
 				    &man, &exp);
 	/* Check if ebs mantissa is too large. */
 	if (exp > ASO_DSEG_EXP_MASK)
@@ -316,11 +358,14 @@ mlx5_flow_mtr_cap_get(struct rte_eth_dev *dev,
 					  RTE_MTR_ERROR_TYPE_UNSPECIFIED, NULL,
 					  "Meter is not supported");
 	memset(cap, 0, sizeof(*cap));
-	if (priv->sh->meter_aso_en)
+	if (priv->sh->meter_aso_en) {
 	    /* 2 meters per one ASO cache line. */
 		cap->n_max = 1 << (qattr->log_max_num_meter_aso + 1);
-	else
+		cap->meter_srtcmp_n_max = qattr->srtcm_sup ? cap->n_max : 0;
+	} else {
 		cap->n_max = 1 << qattr->log_max_flow_meter;
+		cap->meter_srtcmp_n_max = 0;
+	}
 	cap->n_shared_max = cap->n_max;
 	cap->identical = 1;
 	cap->shared_identical = 1;
@@ -382,7 +427,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, error);
+	ret = mlx5_flow_meter_param_fill(fmp, priv, error);
 	if (ret)
 		goto error;
 	/* Add to list. */
@@ -539,7 +584,7 @@ mlx5_flow_meter_validate(struct mlx5_priv *priv, uint32_t meter_id,
 static int
 mlx5_flow_meter_action_modify(struct mlx5_priv *priv,
 		struct mlx5_flow_meter_info *fm,
-		const struct mlx5_flow_meter_srtcm_rfc2697_prm *srtcm,
+		const struct mlx5_flow_meter_srtcm_prm *srtcm,
 		uint64_t modify_bits, uint32_t active_state, uint32_t is_enable)
 {
 #ifdef HAVE_MLX5_DR_CREATE_ACTION_FLOW_METER
@@ -899,7 +944,7 @@ mlx5_flow_meter_modify_state(struct mlx5_priv *priv,
 			     uint32_t new_state,
 			     struct rte_mtr_error *error)
 {
-	static const struct mlx5_flow_meter_srtcm_rfc2697_prm srtcm = {
+	static const struct mlx5_flow_meter_srtcm_prm srtcm = {
 		.cbs_cir = RTE_BE32(MLX5_IFC_FLOW_METER_DISABLE_CBS_CIR_VAL),
 		.ebs_eir = 0,
 	};
-- 
2.21.0

[dpdk-dev] [RFC v3 4/4] app/testpmd: add meter pps mode cmd

[Li Zhang]

Support meter pps mode

Signed-off-by: Li Zhang <lizh@nvidia.com>
---
 app/test-pmd/cmdline.c                      |   4 +
 app/test-pmd/cmdline_mtr.c                  | 105 ++++++++++++++++++++
 app/test-pmd/cmdline_mtr.h                  |   1 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  15 +++
 4 files changed, 125 insertions(+)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index d274a7cb8c..1a3fc644dc 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -698,6 +698,9 @@ static void cmd_help_long_parsed(void *parsed_result,
 			"add port meter profile trtcm_rfc4115 (port_id) (profile_id) (cir) (eir) (cbs) (ebs)\n"
 			"    meter profile add - trtcm rfc 4115\n\n"
 
+			"add port meter profile srtcmp (port_id) (profile_id) (cipr) (cpbs) (epbs)\n"
+			"    meter profile add - srtcmp packet per second\n\n"
+
 			"del port meter profile (port_id) (profile_id)\n"
 			"    meter profile delete\n\n"
 
@@ -17006,6 +17009,7 @@ cmdline_parse_ctx_t main_ctx[] = {
 	(cmdline_parse_inst_t *)&cmd_show_port_meter_cap,
 	(cmdline_parse_inst_t *)&cmd_add_port_meter_profile_srtcm,
 	(cmdline_parse_inst_t *)&cmd_add_port_meter_profile_trtcm,
+	(cmdline_parse_inst_t *)&cmd_add_port_meter_profile_srtcmp,
 	(cmdline_parse_inst_t *)&cmd_del_port_meter_profile,
 	(cmdline_parse_inst_t *)&cmd_create_port_meter,
 	(cmdline_parse_inst_t *)&cmd_enable_port_meter,
diff --git a/app/test-pmd/cmdline_mtr.c b/app/test-pmd/cmdline_mtr.c
index 399ee56e07..3f62240a0d 100644
--- a/app/test-pmd/cmdline_mtr.c
+++ b/app/test-pmd/cmdline_mtr.c
@@ -295,6 +295,8 @@ static void cmd_show_port_meter_cap_parsed(void *parsed_result,
 		cap.meter_trtcm_rfc2698_n_max);
 	printf("cap.meter_trtcm_rfc4115_n_max %" PRIu32 "\n",
 		cap.meter_trtcm_rfc4115_n_max);
+	printf("cap.meter_srtcmp_n_max %" PRIu32 "\n",
+		cap.meter_srtcmp_n_max);
 	printf("cap.meter_rate_max %" PRIu64 "\n", cap.meter_rate_max);
 	printf("cap.color_aware_srtcm_rfc2697_supported %" PRId32 "\n",
 		cap.color_aware_srtcm_rfc2697_supported);
@@ -302,6 +304,8 @@ static void cmd_show_port_meter_cap_parsed(void *parsed_result,
 		cap.color_aware_trtcm_rfc2698_supported);
 	printf("cap.color_aware_trtcm_rfc4115_supported %" PRId32 "\n",
 		cap.color_aware_trtcm_rfc4115_supported);
+	printf("cap.color_aware_srtcmp_supported %" PRId32 "\n",
+		cap.color_aware_srtcmp_supported);
 	printf("cap.policer_action_recolor_supported %" PRId32 "\n",
 		cap.policer_action_recolor_supported);
 	printf("cap.policer_action_drop_supported %" PRId32 "\n",
@@ -644,6 +648,107 @@ cmdline_parse_inst_t cmd_add_port_meter_profile_trtcm_rfc4115 = {
 	},
 };
 
+/* *** Add Port Meter Profile srtcmp *** */
+struct cmd_add_port_meter_profile_srtcmp_result {
+	cmdline_fixed_string_t add;
+	cmdline_fixed_string_t port;
+	cmdline_fixed_string_t meter;
+	cmdline_fixed_string_t profile;
+	cmdline_fixed_string_t srtcmp;
+	uint16_t port_id;
+	uint32_t profile_id;
+	uint64_t cir;
+	uint64_t cbs;
+	uint64_t ebs;
+};
+
+cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcmp_add =
+	TOKEN_STRING_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result, add, "add");
+cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcmp_port =
+	TOKEN_STRING_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			port, "port");
+cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcmp_meter =
+	TOKEN_STRING_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			meter, "meter");
+cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcmp_profile =
+	TOKEN_STRING_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			profile, "profile");
+cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcmp_srtcmp =
+	TOKEN_STRING_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			srtcmp, "srtcmp");
+cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcmp_port_id =
+	TOKEN_NUM_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			port_id, RTE_UINT16);
+cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcmp_profile_id =
+	TOKEN_NUM_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			profile_id, RTE_UINT32);
+cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcmp_cir =
+	TOKEN_NUM_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			cir, RTE_UINT64);
+cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcmp_cbs =
+	TOKEN_NUM_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			cbs, RTE_UINT64);
+cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcmp_ebs =
+	TOKEN_NUM_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			ebs, RTE_UINT64);
+
+static void cmd_add_port_meter_profile_srtcmp_parsed(void *parsed_result,
+	__rte_unused struct cmdline *cl,
+	__rte_unused void *data)
+{
+	struct cmd_add_port_meter_profile_srtcmp_result *res = parsed_result;
+	struct rte_mtr_meter_profile mp;
+	struct rte_mtr_error error;
+	uint32_t profile_id = res->profile_id;
+	uint16_t port_id = res->port_id;
+	int ret;
+
+	if (port_id_is_invalid(port_id, ENABLED_WARN))
+		return;
+
+	/* Private shaper profile params */
+	memset(&mp, 0, sizeof(struct rte_mtr_meter_profile));
+	mp.alg = RTE_MTR_SRTCMP;
+	mp.srtcmp.cir = res->cir;
+	mp.srtcmp.cbs = res->cbs;
+	mp.srtcmp.ebs = res->ebs;
+
+	ret = rte_mtr_meter_profile_add(port_id, profile_id, &mp, &error);
+	if (ret != 0) {
+		print_err_msg(&error);
+		return;
+	}
+}
+
+cmdline_parse_inst_t cmd_add_port_meter_profile_srtcmp = {
+	.f = cmd_add_port_meter_profile_srtcmp_parsed,
+	.data = NULL,
+	.help_str = "Add port meter profile srtcmp",
+	.tokens = {
+		(void *)&cmd_add_port_meter_profile_srtcmp_add,
+		(void *)&cmd_add_port_meter_profile_srtcmp_port,
+		(void *)&cmd_add_port_meter_profile_srtcmp_meter,
+		(void *)&cmd_add_port_meter_profile_srtcmp_profile,
+		(void *)&cmd_add_port_meter_profile_srtcmp_srtcmp,
+		(void *)&cmd_add_port_meter_profile_srtcmp_port_id,
+		(void *)&cmd_add_port_meter_profile_srtcmp_profile_id,
+		(void *)&cmd_add_port_meter_profile_srtcmp_cir,
+		(void *)&cmd_add_port_meter_profile_srtcmp_cbs,
+		(void *)&cmd_add_port_meter_profile_srtcmp_ebs,
+		NULL,
+	},
+};
+
 /* *** Delete Port Meter Profile *** */
 struct cmd_del_port_meter_profile_result {
 	cmdline_fixed_string_t del;
diff --git a/app/test-pmd/cmdline_mtr.h b/app/test-pmd/cmdline_mtr.h
index e69d6da023..01ef85e1e7 100644
--- a/app/test-pmd/cmdline_mtr.h
+++ b/app/test-pmd/cmdline_mtr.h
@@ -10,6 +10,7 @@ extern cmdline_parse_inst_t cmd_show_port_meter_cap;
 extern cmdline_parse_inst_t cmd_add_port_meter_profile_srtcm;
 extern cmdline_parse_inst_t cmd_add_port_meter_profile_trtcm;
 extern cmdline_parse_inst_t cmd_add_port_meter_profile_trtcm_rfc4115;
+extern cmdline_parse_inst_t cmd_add_port_meter_profile_srtcmp;
 extern cmdline_parse_inst_t cmd_del_port_meter_profile;
 extern cmdline_parse_inst_t cmd_create_port_meter;
 extern cmdline_parse_inst_t cmd_enable_port_meter;
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 37278d31d6..d11de05583 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -2734,6 +2734,21 @@ where:
 * ``cbs``: Committed burst size (bytes).
 * ``ebs``: Excess burst size (bytes).
 
+add port meter profile (srTcmp)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Add meter profile (srTcmp) to the ethernet device::
+
+   testpmd> add port meter profile srtcmp (port_id) (profile_id) \
+   (cir) (cbs) (ebs)
+
+where:
+
+* ``profile_id``: ID for the meter profile.
+* ``cpr``: Committed Information Rate (CIR) (packets/second).
+* ``cbs``: Committed Burst Size (CBS) (packets).
+* ``ebs``: Excess Burst Size (EBS) (packets).
+
 delete port meter profile
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
-- 
2.21.0

[dpdk-dev] [RFC v3 0/4] adds support PPS(packet per second) on meter

[Li Zhang]

v3:
* Redefine the struct name for PPS mode.

v2:
* Rebase


Li Zhang (4):
  ethdev: add meter PPS profile
  common/mlx5: add meter mode definition in PRM file
  net/mlx5: support meter PPS profile
  app/testpmd: add meter pps mode cmd

 app/test-pmd/cmdline.c                        |   4 +
 app/test-pmd/cmdline_mtr.c                    | 105 ++++++++++++++++++
 app/test-pmd/cmdline_mtr.h                    |   1 +
 doc/guides/nics/mlx5.rst                      |   1 +
 .../traffic_metering_and_policing.rst         |   3 +-
 doc/guides/rel_notes/release_20_11.rst        |   5 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst   |  15 +++
 drivers/common/mlx5/mlx5_prm.h                |   8 ++
 drivers/net/mlx5/mlx5.h                       |  13 ++-
 drivers/net/mlx5/mlx5_flow_aso.c              |  17 ++-
 drivers/net/mlx5/mlx5_flow_meter.c            |  71 +++++++++---
 lib/librte_ethdev/rte_mtr.h                   |  32 ++++++
 12 files changed, 251 insertions(+), 24 deletions(-)

-- 
2.21.0

[dpdk-dev] [RFC v3 1/4] ethdev: add meter PPS profile

[Li Zhang]

Currently meter algorithms only supports rate is bytes per second(BPS).
Add this new meter srTCMp algorithm to support rate is packet per second.
So that it can meter traffic by packet per second.
The below structure will be extended:
rte_mtr_algorithm
rte_mtr_meter_profile
Signed-off-by: Li Zhang <lizh@nvidia.com>
---
 .../traffic_metering_and_policing.rst         |  3 +-
 doc/guides/rel_notes/release_20_11.rst        |  5 +++
 lib/librte_ethdev/rte_mtr.h                   | 32 +++++++++++++++++++
 3 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/doc/guides/prog_guide/traffic_metering_and_policing.rst b/doc/guides/prog_guide/traffic_metering_and_policing.rst
index 90c781eb1d..4d2405d44a 100644
--- a/doc/guides/prog_guide/traffic_metering_and_policing.rst
+++ b/doc/guides/prog_guide/traffic_metering_and_policing.rst
@@ -17,7 +17,8 @@ The main features are:
 * Part of DPDK rte_ethdev API
 * Capability query API
 * Metering algorithms: RFC 2697 Single Rate Three Color Marker (srTCM), RFC 2698
-  and RFC 4115 Two Rate Three Color Marker (trTCM)
+  and RFC 4115 Two Rate Three Color Marker (trTCM),
+  Single Rate Three Color Marker, Packet based (srTCMp).
 * Policer actions (per meter output color): recolor, drop
 * Statistics (per policer output color)
 
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index 7405a9864f..de04886cc9 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -429,6 +429,11 @@ New Features
   can leverage IOAT DMA channels with vhost asynchronous APIs.
   See the :doc:`../sample_app_ug/vhost` for more details.
 
+* **Added support for meter PPS profile.**
+
+  Currently meter algorithms only supports bytes per second(BPS).
+  Add this new meter algorithm to support packet per second (PPS) mode.
+  So that it can meter traffic by packet per second.
 
 Removed Items
 -------------
diff --git a/lib/librte_ethdev/rte_mtr.h b/lib/librte_ethdev/rte_mtr.h
index 916a09c5c3..f27a4b5354 100644
--- a/lib/librte_ethdev/rte_mtr.h
+++ b/lib/librte_ethdev/rte_mtr.h
@@ -119,6 +119,11 @@ enum rte_mtr_algorithm {
 
 	/** Two Rate Three Color Marker (trTCM) - IETF RFC 4115. */
 	RTE_MTR_TRTCM_RFC4115,
+
+	/** Single Rate Three Color Marker, Packet based (srTCMp).
+	 * - - similar to IETF RFC 2697 but rate is packet per second.
+	 */
+	RTE_MTR_SRTCMP,
 };
 
 /**
@@ -171,6 +176,20 @@ struct rte_mtr_meter_profile {
 			/** Excess Burst Size (EBS) (bytes). */
 			uint64_t ebs;
 		} trtcm_rfc4115;
+
+		/** Items only valid when *alg* is set to srTCMp. */
+		struct {
+			/** Committed Information Rate (CIR)
+			 * (packets/second).
+			 */
+			uint64_t cir;
+
+			/** Committed Burst Size (CBS) (packets). */
+			uint64_t cbs;
+
+			/** Excess Burst Size (EBS) (packets). */
+			uint64_t ebs;
+		} srtcmp;
 	};
 };
 
@@ -317,6 +336,13 @@ struct rte_mtr_capabilities {
 	 */
 	uint32_t meter_trtcm_rfc4115_n_max;
 
+	/** Maximum number of MTR objects that can have their meter configured
+	 * to run the srTCMp algorithm. The value of 0
+	 * indicates this metering algorithm is not supported.
+	 * The maximum value is *n_max*.
+	 */
+	uint32_t meter_srtcmp_n_max;
+
 	/** Maximum traffic rate that can be metered by a single MTR object. For
 	 * srTCM RFC 2697, this is the maximum CIR rate. For trTCM RFC 2698,
 	 * this is the maximum PIR rate. For trTCM RFC 4115, this is the maximum
@@ -342,6 +368,12 @@ struct rte_mtr_capabilities {
 	 */
 	int color_aware_trtcm_rfc4115_supported;
 
+	/**
+	 * When non-zero, it indicates that color aware mode is supported for
+	 * the srTCMp metering algorithm.
+	 */
+	int color_aware_srtcmp_supported;
+
 	/** When non-zero, it indicates that the policer packet recolor actions
 	 * are supported.
 	 * @see enum rte_mtr_policer_action
-- 
2.21.0

[dpdk-dev] [RFC v3 2/4] common/mlx5: add meter mode definition in PRM file

[Li Zhang]

Add meter mode definition in PRM file

Signed-off-by: Li Zhang <lizh@nvidia.com>
---
 drivers/common/mlx5/mlx5_prm.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/common/mlx5/mlx5_prm.h b/drivers/common/mlx5/mlx5_prm.h
index e3d4120849..609b1c3951 100644
--- a/drivers/common/mlx5/mlx5_prm.h
+++ b/drivers/common/mlx5/mlx5_prm.h
@@ -2177,6 +2177,13 @@ struct mlx5_ifc_flow_meter_parameters_bits {
 #define MLX5_IFC_FLOW_METER_PARAM_MASK UINT64_C(0x80FFFFFF)
 #define MLX5_IFC_FLOW_METER_DISABLE_CBS_CIR_VAL 0x14BF00C8
 
+enum {
+	MLX5_METER_MODE_IP_LEN = 0x0,
+	MLX5_METER_MODE_L2_LEN = 0x1,
+	MLX5_METER_MODE_L2_IPG_LEN = 0x2,
+	MLX5_METER_MODE_PKT = 0x3,
+};
+
 enum {
 	MLX5_CQE_SIZE_64B = 0x0,
 	MLX5_CQE_SIZE_128B = 0x1,
@@ -2508,6 +2515,7 @@ struct mlx5_aso_mtr_dseg {
 #define ASO_DSEG_VALID_OFFSET 31
 #define ASO_DSEG_BO_OFFSET 30
 #define ASO_DSEG_SC_OFFSET 28
+#define ASO_DSEG_MTR_MODE 24
 #define ASO_DSEG_CBS_EXP_OFFSET 24
 #define ASO_DSEG_CBS_MAN_OFFSET 16
 #define ASO_DSEG_CIR_EXP_MASK 0x1F
-- 
2.21.0

[dpdk-dev] [RFC v3 3/4] net/mlx5: support meter PPS profile

[Li Zhang]

Currently meter algorithms only supports bytes per second(BPS).
Such as Single Rate Three Color Marker (srTCM rfc2697)
Add this new meter srTCMp algorithm to support rate is packet per second.
So that it can meter traffic by packet per second (PPS).

Signed-off-by: Li Zhang <lizh@nvidia.com>
---
 doc/guides/nics/mlx5.rst           |  1 +
 drivers/net/mlx5/mlx5.h            | 13 ++++--
 drivers/net/mlx5/mlx5_flow_aso.c   | 17 ++++---
 drivers/net/mlx5/mlx5_flow_meter.c | 71 ++++++++++++++++++++++++------
 4 files changed, 79 insertions(+), 23 deletions(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index a390a4b53c..93f5c0e4d4 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -362,6 +362,7 @@ Limitations
   - Green color is not supported with drop action.
   - Yellow detection is not supported.
   - Red color must be with drop action.
+  - meter srTCMp algorithm is supported.
 
 Statistics
 ----------
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index 2790995dcc..16fa1b6c4d 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -742,8 +742,13 @@ struct mlx5_flow_meter_info {
 	/**< Flow meter action. */
 };
 
-/* RFC2697 parameter structure. */
-struct mlx5_flow_meter_srtcm_rfc2697_prm {
+/* PPS(packets per second) map to BPS(Bytes per second).
+ * HW treat packet as 128bytes in PPS mode
+ */
+#define MLX5_MTRS_PPS_MAP_BPS_SHIFT 7
+
+/* RFC2697/PPS parameter structure. */
+struct mlx5_flow_meter_srtcm_prm {
 	rte_be32_t cbs_cir;
 	/*
 	 * bit 24-28: cbs_exponent, bit 16-23 cbs_mantissa,
@@ -763,8 +768,8 @@ struct mlx5_flow_meter_profile {
 	uint32_t id; /**< Profile id. */
 	struct rte_mtr_meter_profile profile; /**< Profile detail. */
 	union {
-		struct mlx5_flow_meter_srtcm_rfc2697_prm srtcm_prm;
-		/**< srtcm_rfc2697 struct. */
+		struct mlx5_flow_meter_srtcm_prm srtcm_prm;
+		/**< srtcm_rfc2697/srtcm_pps struct. */
 	};
 	uint32_t ref_cnt; /**< Use count. */
 };
diff --git a/drivers/net/mlx5/mlx5_flow_aso.c b/drivers/net/mlx5/mlx5_flow_aso.c
index c9280b1f9d..3f3ba7e8fa 100644
--- a/drivers/net/mlx5/mlx5_flow_aso.c
+++ b/drivers/net/mlx5/mlx5_flow_aso.c
@@ -244,7 +244,6 @@ mlx5_aso_mtr_init_sq(struct mlx5_aso_sq *sq)
 	volatile struct mlx5_aso_wqe *restrict wqe;
 	int i;
 	int size = 1 << sq->log_desc_n;
-	uint32_t idx;
 
 	/* All the next fields state should stay constant. */
 	for (i = 0, wqe = &sq->wqes[0]; i < size; ++i, ++wqe) {
@@ -257,11 +256,6 @@ mlx5_aso_mtr_init_sq(struct mlx5_aso_sq *sq)
 			 (BYTEWISE_64BYTE << ASO_CSEG_DATA_MASK_MODE_OFFSET));
 		wqe->general_cseg.flags = RTE_BE32(MLX5_COMP_ALWAYS <<
 							 MLX5_COMP_MODE_OFFSET);
-		for (idx = 0; idx < MLX5_ASO_METERS_PER_WQE;
-			idx++)
-			wqe->aso_dseg.mtrs[idx].v_bo_sc_bbog_mm =
-				RTE_BE32((1 << ASO_DSEG_VALID_OFFSET) |
-				(MLX5_FLOW_COLOR_GREEN << ASO_DSEG_SC_OFFSET));
 	}
 }
 
@@ -744,6 +738,7 @@ mlx5_aso_mtr_sq_enqueue_single(struct mlx5_aso_sq *sq,
 {
 	volatile struct mlx5_aso_wqe *wqe = NULL;
 	struct mlx5_flow_meter_info *fm = NULL;
+	struct mlx5_flow_meter_profile *fmp;
 	uint16_t size = 1 << sq->log_desc_n;
 	uint16_t mask = size - 1;
 	uint16_t res = size - (uint16_t)(sq->head - sq->tail);
@@ -781,6 +776,16 @@ mlx5_aso_mtr_sq_enqueue_single(struct mlx5_aso_sq *sq,
 			RTE_BE32(MLX5_IFC_FLOW_METER_DISABLE_CBS_CIR_VAL);
 		wqe->aso_dseg.mtrs[dseg_idx].ebs_eir = 0;
 	}
+	fmp = fm->profile;
+	if (fmp->profile.alg == RTE_MTR_SRTCMP)
+		wqe->aso_dseg.mtrs[dseg_idx].v_bo_sc_bbog_mm =
+				RTE_BE32((1 << ASO_DSEG_VALID_OFFSET) |
+				(MLX5_FLOW_COLOR_GREEN << ASO_DSEG_SC_OFFSET) |
+				(MLX5_METER_MODE_PKT << ASO_DSEG_MTR_MODE));
+	else
+		wqe->aso_dseg.mtrs[dseg_idx].v_bo_sc_bbog_mm =
+				RTE_BE32((1 << ASO_DSEG_VALID_OFFSET) |
+				(MLX5_FLOW_COLOR_GREEN << ASO_DSEG_SC_OFFSET));
 	sq->head++;
 	sq->pi += 2;/* Each WQE contains 2 WQEBB's. */
 	rte_io_wmb();
diff --git a/drivers/net/mlx5/mlx5_flow_meter.c b/drivers/net/mlx5/mlx5_flow_meter.c
index 49f6229ae6..cf2fe8c173 100644
--- a/drivers/net/mlx5/mlx5_flow_meter.c
+++ b/drivers/net/mlx5/mlx5_flow_meter.c
@@ -33,7 +33,7 @@ mlx5_flow_meter_action_create(struct mlx5_priv *priv,
 #ifdef HAVE_MLX5_DR_CREATE_ACTION_FLOW_METER
 	struct mlx5dv_dr_flow_meter_attr mtr_init;
 	uint32_t fmp[MLX5_ST_SZ_DW(flow_meter_parameters)];
-	struct mlx5_flow_meter_srtcm_rfc2697_prm *srtcm =
+	struct mlx5_flow_meter_srtcm_prm *srtcm =
 						     &fm->profile->srtcm_prm;
 	uint32_t cbs_cir = rte_be_to_cpu_32(srtcm->cbs_cir);
 	uint32_t ebs_eir = rte_be_to_cpu_32(srtcm->ebs_eir);
@@ -157,6 +157,32 @@ mlx5_flow_meter_profile_validate(struct rte_eth_dev *dev,
 					      "Invalid metering parameters.");
 		}
 	}
+	if (priv->sh->meter_aso_en &&
+		profile->alg == RTE_MTR_SRTCMP) {
+		if (priv->config.hca_attr.qos.srtcm_sup) {
+			/* Verify support for flow meter parameters. */
+			if (profile->srtcmp.cir > 0 &&
+			    (profile->srtcmp.cir <<
+					MLX5_MTRS_PPS_MAP_BPS_SHIFT)
+						<= MLX5_SRTCM_CIR_MAX &&
+			    profile->srtcmp.cbs > 0 &&
+			    (profile->srtcmp.cbs <<
+					MLX5_MTRS_PPS_MAP_BPS_SHIFT)
+						<= MLX5_SRTCM_CBS_MAX &&
+			    (profile->srtcmp.ebs <<
+					MLX5_MTRS_PPS_MAP_BPS_SHIFT)
+						<= MLX5_SRTCM_EBS_MAX)
+				return 0;
+			else
+				return -rte_mtr_error_set
+					     (error, ENOTSUP,
+					      RTE_MTR_ERROR_TYPE_MTR_PARAMS,
+					      NULL,
+					      profile->srtcmp.ebs ?
+					      "Metering value ebs must be 0." :
+					      "Invalid metering parameters.");
+		}
+	}
 	return -rte_mtr_error_set(error, ENOTSUP,
 				  RTE_MTR_ERROR_TYPE_METER_PROFILE,
 				  NULL, "Metering algorithm not supported.");
@@ -238,19 +264,35 @@ 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 rte_mtr_error *error)
+			struct mlx5_priv *priv, struct rte_mtr_error *error)
 {
-	struct mlx5_flow_meter_srtcm_rfc2697_prm *srtcm = &fmp->srtcm_prm;
+	struct mlx5_flow_meter_srtcm_prm *srtcm = &fmp->srtcm_prm;
 	uint8_t man, exp;
 	uint32_t cbs_exp, cbs_man, cir_exp, cir_man;
 	uint32_t ebs_exp, ebs_man;
+	uint64_t cir, cbs, ebs;
 
-	if (fmp->profile.alg != RTE_MTR_SRTCM_RFC2697)
-		return -rte_mtr_error_set(error, ENOTSUP,
+	if (fmp->profile.alg == RTE_MTR_SRTCM_RFC2697) {
+		cir = fmp->profile.srtcm_rfc2697.cir;
+		cbs = fmp->profile.srtcm_rfc2697.cbs;
+		ebs = fmp->profile.srtcm_rfc2697.ebs;
+	} else {
+		if (priv->sh->meter_aso_en &&
+			fmp->profile.alg == RTE_MTR_SRTCMP) {
+			cir = fmp->profile.srtcmp.cir <<
+				MLX5_MTRS_PPS_MAP_BPS_SHIFT;
+			cbs = fmp->profile.srtcmp.cbs <<
+				MLX5_MTRS_PPS_MAP_BPS_SHIFT;
+			ebs = fmp->profile.srtcmp.ebs <<
+				MLX5_MTRS_PPS_MAP_BPS_SHIFT;
+		} else {
+			return -rte_mtr_error_set(error, ENOTSUP,
 				RTE_MTR_ERROR_TYPE_METER_PROFILE,
 				NULL, "Metering algorithm not supported.");
+		}
+	}
 	/* cir = 8G * cir_mantissa * 1/(2^cir_exponent)) Bytes/Sec */
-	mlx5_flow_meter_cir_man_exp_calc(fmp->profile.srtcm_rfc2697.cir,
+	mlx5_flow_meter_cir_man_exp_calc(cir,
 				    &man, &exp);
 	/* Check if cir mantissa is too large. */
 	if (exp > ASO_DSEG_CIR_EXP_MASK)
@@ -261,7 +303,7 @@ mlx5_flow_meter_param_fill(struct mlx5_flow_meter_profile *fmp,
 	cir_man = man;
 	cir_exp = exp;
 	 /* cbs = cbs_mantissa * 2^cbs_exponent */
-	mlx5_flow_meter_xbs_man_exp_calc(fmp->profile.srtcm_rfc2697.cbs,
+	mlx5_flow_meter_xbs_man_exp_calc(cbs,
 				    &man, &exp);
 	/* Check if cbs mantissa is too large. */
 	if (exp > ASO_DSEG_EXP_MASK)
@@ -275,7 +317,7 @@ mlx5_flow_meter_param_fill(struct mlx5_flow_meter_profile *fmp,
 				cbs_man << ASO_DSEG_CBS_MAN_OFFSET |
 				cir_exp << ASO_DSEG_CIR_EXP_OFFSET |
 				cir_man);
-	mlx5_flow_meter_xbs_man_exp_calc(fmp->profile.srtcm_rfc2697.ebs,
+	mlx5_flow_meter_xbs_man_exp_calc(ebs,
 				    &man, &exp);
 	/* Check if ebs mantissa is too large. */
 	if (exp > ASO_DSEG_EXP_MASK)
@@ -316,11 +358,14 @@ mlx5_flow_mtr_cap_get(struct rte_eth_dev *dev,
 					  RTE_MTR_ERROR_TYPE_UNSPECIFIED, NULL,
 					  "Meter is not supported");
 	memset(cap, 0, sizeof(*cap));
-	if (priv->sh->meter_aso_en)
+	if (priv->sh->meter_aso_en) {
 	    /* 2 meters per one ASO cache line. */
 		cap->n_max = 1 << (qattr->log_max_num_meter_aso + 1);
-	else
+		cap->meter_srtcmp_n_max = qattr->srtcm_sup ? cap->n_max : 0;
+	} else {
 		cap->n_max = 1 << qattr->log_max_flow_meter;
+		cap->meter_srtcmp_n_max = 0;
+	}
 	cap->n_shared_max = cap->n_max;
 	cap->identical = 1;
 	cap->shared_identical = 1;
@@ -382,7 +427,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, error);
+	ret = mlx5_flow_meter_param_fill(fmp, priv, error);
 	if (ret)
 		goto error;
 	/* Add to list. */
@@ -539,7 +584,7 @@ mlx5_flow_meter_validate(struct mlx5_priv *priv, uint32_t meter_id,
 static int
 mlx5_flow_meter_action_modify(struct mlx5_priv *priv,
 		struct mlx5_flow_meter_info *fm,
-		const struct mlx5_flow_meter_srtcm_rfc2697_prm *srtcm,
+		const struct mlx5_flow_meter_srtcm_prm *srtcm,
 		uint64_t modify_bits, uint32_t active_state, uint32_t is_enable)
 {
 #ifdef HAVE_MLX5_DR_CREATE_ACTION_FLOW_METER
@@ -899,7 +944,7 @@ mlx5_flow_meter_modify_state(struct mlx5_priv *priv,
 			     uint32_t new_state,
 			     struct rte_mtr_error *error)
 {
-	static const struct mlx5_flow_meter_srtcm_rfc2697_prm srtcm = {
+	static const struct mlx5_flow_meter_srtcm_prm srtcm = {
 		.cbs_cir = RTE_BE32(MLX5_IFC_FLOW_METER_DISABLE_CBS_CIR_VAL),
 		.ebs_eir = 0,
 	};
-- 
2.21.0

[dpdk-dev] [RFC v3 4/4] app/testpmd: add meter pps mode cmd

[Li Zhang]

Support meter pps mode

Signed-off-by: Li Zhang <lizh@nvidia.com>
---
 app/test-pmd/cmdline.c                      |   4 +
 app/test-pmd/cmdline_mtr.c                  | 105 ++++++++++++++++++++
 app/test-pmd/cmdline_mtr.h                  |   1 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  15 +++
 4 files changed, 125 insertions(+)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index d274a7cb8c..1a3fc644dc 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -698,6 +698,9 @@ static void cmd_help_long_parsed(void *parsed_result,
 			"add port meter profile trtcm_rfc4115 (port_id) (profile_id) (cir) (eir) (cbs) (ebs)\n"
 			"    meter profile add - trtcm rfc 4115\n\n"
 
+			"add port meter profile srtcmp (port_id) (profile_id) (cipr) (cpbs) (epbs)\n"
+			"    meter profile add - srtcmp packet per second\n\n"
+
 			"del port meter profile (port_id) (profile_id)\n"
 			"    meter profile delete\n\n"
 
@@ -17006,6 +17009,7 @@ cmdline_parse_ctx_t main_ctx[] = {
 	(cmdline_parse_inst_t *)&cmd_show_port_meter_cap,
 	(cmdline_parse_inst_t *)&cmd_add_port_meter_profile_srtcm,
 	(cmdline_parse_inst_t *)&cmd_add_port_meter_profile_trtcm,
+	(cmdline_parse_inst_t *)&cmd_add_port_meter_profile_srtcmp,
 	(cmdline_parse_inst_t *)&cmd_del_port_meter_profile,
 	(cmdline_parse_inst_t *)&cmd_create_port_meter,
 	(cmdline_parse_inst_t *)&cmd_enable_port_meter,
diff --git a/app/test-pmd/cmdline_mtr.c b/app/test-pmd/cmdline_mtr.c
index 399ee56e07..3f62240a0d 100644
--- a/app/test-pmd/cmdline_mtr.c
+++ b/app/test-pmd/cmdline_mtr.c
@@ -295,6 +295,8 @@ static void cmd_show_port_meter_cap_parsed(void *parsed_result,
 		cap.meter_trtcm_rfc2698_n_max);
 	printf("cap.meter_trtcm_rfc4115_n_max %" PRIu32 "\n",
 		cap.meter_trtcm_rfc4115_n_max);
+	printf("cap.meter_srtcmp_n_max %" PRIu32 "\n",
+		cap.meter_srtcmp_n_max);
 	printf("cap.meter_rate_max %" PRIu64 "\n", cap.meter_rate_max);
 	printf("cap.color_aware_srtcm_rfc2697_supported %" PRId32 "\n",
 		cap.color_aware_srtcm_rfc2697_supported);
@@ -302,6 +304,8 @@ static void cmd_show_port_meter_cap_parsed(void *parsed_result,
 		cap.color_aware_trtcm_rfc2698_supported);
 	printf("cap.color_aware_trtcm_rfc4115_supported %" PRId32 "\n",
 		cap.color_aware_trtcm_rfc4115_supported);
+	printf("cap.color_aware_srtcmp_supported %" PRId32 "\n",
+		cap.color_aware_srtcmp_supported);
 	printf("cap.policer_action_recolor_supported %" PRId32 "\n",
 		cap.policer_action_recolor_supported);
 	printf("cap.policer_action_drop_supported %" PRId32 "\n",
@@ -644,6 +648,107 @@ cmdline_parse_inst_t cmd_add_port_meter_profile_trtcm_rfc4115 = {
 	},
 };
 
+/* *** Add Port Meter Profile srtcmp *** */
+struct cmd_add_port_meter_profile_srtcmp_result {
+	cmdline_fixed_string_t add;
+	cmdline_fixed_string_t port;
+	cmdline_fixed_string_t meter;
+	cmdline_fixed_string_t profile;
+	cmdline_fixed_string_t srtcmp;
+	uint16_t port_id;
+	uint32_t profile_id;
+	uint64_t cir;
+	uint64_t cbs;
+	uint64_t ebs;
+};
+
+cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcmp_add =
+	TOKEN_STRING_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result, add, "add");
+cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcmp_port =
+	TOKEN_STRING_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			port, "port");
+cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcmp_meter =
+	TOKEN_STRING_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			meter, "meter");
+cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcmp_profile =
+	TOKEN_STRING_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			profile, "profile");
+cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcmp_srtcmp =
+	TOKEN_STRING_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			srtcmp, "srtcmp");
+cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcmp_port_id =
+	TOKEN_NUM_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			port_id, RTE_UINT16);
+cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcmp_profile_id =
+	TOKEN_NUM_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			profile_id, RTE_UINT32);
+cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcmp_cir =
+	TOKEN_NUM_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			cir, RTE_UINT64);
+cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcmp_cbs =
+	TOKEN_NUM_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			cbs, RTE_UINT64);
+cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcmp_ebs =
+	TOKEN_NUM_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			ebs, RTE_UINT64);
+
+static void cmd_add_port_meter_profile_srtcmp_parsed(void *parsed_result,
+	__rte_unused struct cmdline *cl,
+	__rte_unused void *data)
+{
+	struct cmd_add_port_meter_profile_srtcmp_result *res = parsed_result;
+	struct rte_mtr_meter_profile mp;
+	struct rte_mtr_error error;
+	uint32_t profile_id = res->profile_id;
+	uint16_t port_id = res->port_id;
+	int ret;
+
+	if (port_id_is_invalid(port_id, ENABLED_WARN))
+		return;
+
+	/* Private shaper profile params */
+	memset(&mp, 0, sizeof(struct rte_mtr_meter_profile));
+	mp.alg = RTE_MTR_SRTCMP;
+	mp.srtcmp.cir = res->cir;
+	mp.srtcmp.cbs = res->cbs;
+	mp.srtcmp.ebs = res->ebs;
+
+	ret = rte_mtr_meter_profile_add(port_id, profile_id, &mp, &error);
+	if (ret != 0) {
+		print_err_msg(&error);
+		return;
+	}
+}
+
+cmdline_parse_inst_t cmd_add_port_meter_profile_srtcmp = {
+	.f = cmd_add_port_meter_profile_srtcmp_parsed,
+	.data = NULL,
+	.help_str = "Add port meter profile srtcmp",
+	.tokens = {
+		(void *)&cmd_add_port_meter_profile_srtcmp_add,
+		(void *)&cmd_add_port_meter_profile_srtcmp_port,
+		(void *)&cmd_add_port_meter_profile_srtcmp_meter,
+		(void *)&cmd_add_port_meter_profile_srtcmp_profile,
+		(void *)&cmd_add_port_meter_profile_srtcmp_srtcmp,
+		(void *)&cmd_add_port_meter_profile_srtcmp_port_id,
+		(void *)&cmd_add_port_meter_profile_srtcmp_profile_id,
+		(void *)&cmd_add_port_meter_profile_srtcmp_cir,
+		(void *)&cmd_add_port_meter_profile_srtcmp_cbs,
+		(void *)&cmd_add_port_meter_profile_srtcmp_ebs,
+		NULL,
+	},
+};
+
 /* *** Delete Port Meter Profile *** */
 struct cmd_del_port_meter_profile_result {
 	cmdline_fixed_string_t del;
diff --git a/app/test-pmd/cmdline_mtr.h b/app/test-pmd/cmdline_mtr.h
index e69d6da023..01ef85e1e7 100644
--- a/app/test-pmd/cmdline_mtr.h
+++ b/app/test-pmd/cmdline_mtr.h
@@ -10,6 +10,7 @@ extern cmdline_parse_inst_t cmd_show_port_meter_cap;
 extern cmdline_parse_inst_t cmd_add_port_meter_profile_srtcm;
 extern cmdline_parse_inst_t cmd_add_port_meter_profile_trtcm;
 extern cmdline_parse_inst_t cmd_add_port_meter_profile_trtcm_rfc4115;
+extern cmdline_parse_inst_t cmd_add_port_meter_profile_srtcmp;
 extern cmdline_parse_inst_t cmd_del_port_meter_profile;
 extern cmdline_parse_inst_t cmd_create_port_meter;
 extern cmdline_parse_inst_t cmd_enable_port_meter;
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 37278d31d6..d11de05583 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -2734,6 +2734,21 @@ where:
 * ``cbs``: Committed burst size (bytes).
 * ``ebs``: Excess burst size (bytes).
 
+add port meter profile (srTcmp)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Add meter profile (srTcmp) to the ethernet device::
+
+   testpmd> add port meter profile srtcmp (port_id) (profile_id) \
+   (cir) (cbs) (ebs)
+
+where:
+
+* ``profile_id``: ID for the meter profile.
+* ``cpr``: Committed Information Rate (CIR) (packets/second).
+* ``cbs``: Committed Burst Size (CBS) (packets).
+* ``ebs``: Excess Burst Size (EBS) (packets).
+
 delete port meter profile
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
-- 
2.21.0

Re: [dpdk-dev] [PATCH] [RFC]: adds support PPS(packet per second) on meter

[Ajit Khaparde]

[-- Attachment #1: Type: text/plain, Size: 3127 bytes --]

On Sun, Jan 24, 2021 at 5:02 PM Li Zhang <lizh@nvidia.com> wrote:

> Currently the flow Meter algorithms in rte_flow only supports bytes per
> second(BPS).
> Such as Single Rate Three Color Marker (srTCM rfc2697)
> This RFC adds the packet per second definition in Meter algorithms
> structure,
> to support the rte_mtr APIs with type srTCM pps mode.
>
I thought rfc2697 specified metering using BPS only.
The CIR was measured in bytes per second for IP packets.
Is there a draft or link to the new srTCM mode?



> The below structure will be extended:
> rte_mtr_algorithm
> rte_mtr_meter_profile
> Signed-off-by: Li Zhang <lizh@nvidia.com>
> ---
>  lib/librte_ethdev/rte_mtr.h | 28 ++++++++++++++++++++++++++++
>  1 file changed, 28 insertions(+)
>
> diff --git a/lib/librte_ethdev/rte_mtr.h b/lib/librte_ethdev/rte_mtr.h
> index 916a09c5c3..6413892aec 100644
> --- a/lib/librte_ethdev/rte_mtr.h
> +++ b/lib/librte_ethdev/rte_mtr.h
> @@ -119,6 +119,9 @@ enum rte_mtr_algorithm {
>
>         /** Two Rate Three Color Marker (trTCM) - IETF RFC 4115. */
>         RTE_MTR_TRTCM_RFC4115,
> +
> +       /** Single Rate Three Color Marker (srTCM) in Packet per second
> mode */
> +       RTE_MTR_SRTCM_PPS,
>  };
>
>  /**
> @@ -171,6 +174,18 @@ struct rte_mtr_meter_profile {
>                         /** Excess Burst Size (EBS) (bytes). */
>                         uint64_t ebs;
>                 } trtcm_rfc4115;
> +
> +               /** Items only valid when *alg* is set to srTCM - PPS. */
> +               struct {
> +                       /** Committed Information Rate
> (CIR)(packets/second). */
> +                       uint64_t cir;
> +
> +                       /** Committed Burst Size (CBS) (bytes). */
> +                       uint64_t cbs;
> +
> +                       /** Excess Burst Size (EBS) (bytes). */
> +                       uint64_t ebs;
> +               } srtcm_pps;
>         };
>  };
>
> @@ -317,6 +332,13 @@ struct rte_mtr_capabilities {
>          */
>         uint32_t meter_trtcm_rfc4115_n_max;
>
> +       /** Maximum number of MTR objects that can have their meter
> configured
> +        * to run the srTCM packet per second algorithm. The value of 0
> +        * indicates this metering algorithm is not supported.
> +        * The maximum value is *n_max*.
> +        */
> +       uint32_t meter_srtcm_pps_n_max;
> +
>         /** Maximum traffic rate that can be metered by a single MTR
> object. For
>          * srTCM RFC 2697, this is the maximum CIR rate. For trTCM RFC
> 2698,
>          * this is the maximum PIR rate. For trTCM RFC 4115, this is the
> maximum
> @@ -342,6 +364,12 @@ struct rte_mtr_capabilities {
>          */
>         int color_aware_trtcm_rfc4115_supported;
>
> +       /**
> +       * When non-zero, it indicates that color aware mode is supported
> for
> +       * the srTCM packet per second  metering algorithm.
> +       */
> +       int color_aware_srtcm_pps_supported;
> +
>         /** When non-zero, it indicates that the policer packet recolor
> actions
>          * are supported.
>          * @see enum rte_mtr_policer_action
> --
> 2.21.0
>
>

Re: [dpdk-dev] [PATCH] [RFC]: adds support PPS(packet per second) on meter

[Li Zhang]

Yes, RFC2697 is using BPS only.
We change srTCM_PPS mode name to sprTCM.
Single Packet Rate Three Color Marker (sprTCM) - - similar to IETF RFC 2697 but rate is packet per second.
There is no draft or link to this new mode (sprTCM)

Regards,
Li Zhang
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Ajit Khaparde
> Sent: Saturday, February 13, 2021 5:36 AM
> To: Li Zhang <lizh@nvidia.com>
> Cc: Dekel Peled <dekelp@nvidia.com>; Ori Kam <orika@nvidia.com>; Slava
> Ovsiienko <viacheslavo@nvidia.com>; Matan Azrad <matan@nvidia.com>;
> dpdk-dev <dev@dpdk.org>; NBU-Contact-Thomas Monjalon
> <thomas@monjalon.net>; Raslan Darawsheh <rasland@nvidia.com>
> Subject: Re: [dpdk-dev] [PATCH] [RFC]: adds support PPS(packet per second) on
> meter
> 
> On Sun, Jan 24, 2021 at 5:02 PM Li Zhang <lizh@nvidia.com> wrote:
> 
> > Currently the flow Meter algorithms in rte_flow only supports bytes
> > per second(BPS).
> > Such as Single Rate Three Color Marker (srTCM rfc2697) This RFC adds
> > the packet per second definition in Meter algorithms structure, to
> > support the rte_mtr APIs with type srTCM pps mode.
> >
> I thought rfc2697 specified metering using BPS only.
> The CIR was measured in bytes per second for IP packets.
> Is there a draft or link to the new srTCM mode?
> 
> 
> 
> > The below structure will be extended:
> > rte_mtr_algorithm
> > rte_mtr_meter_profile
> > Signed-off-by: Li Zhang <lizh@nvidia.com>
> > ---
> >  lib/librte_ethdev/rte_mtr.h | 28 ++++++++++++++++++++++++++++
> >  1 file changed, 28 insertions(+)
> >
> > diff --git a/lib/librte_ethdev/rte_mtr.h b/lib/librte_ethdev/rte_mtr.h
> > index 916a09c5c3..6413892aec 100644
> > --- a/lib/librte_ethdev/rte_mtr.h
> > +++ b/lib/librte_ethdev/rte_mtr.h
> > @@ -119,6 +119,9 @@ enum rte_mtr_algorithm {
> >
> >         /** Two Rate Three Color Marker (trTCM) - IETF RFC 4115. */
> >         RTE_MTR_TRTCM_RFC4115,
> > +
> > +       /** Single Rate Three Color Marker (srTCM) in Packet per
> > + second
> > mode */
> > +       RTE_MTR_SRTCM_PPS,
> >  };
> >
> >  /**
> > @@ -171,6 +174,18 @@ struct rte_mtr_meter_profile {
> >                         /** Excess Burst Size (EBS) (bytes). */
> >                         uint64_t ebs;
> >                 } trtcm_rfc4115;
> > +
> > +               /** Items only valid when *alg* is set to srTCM - PPS. */
> > +               struct {
> > +                       /** Committed Information Rate
> > (CIR)(packets/second). */
> > +                       uint64_t cir;
> > +
> > +                       /** Committed Burst Size (CBS) (bytes). */
> > +                       uint64_t cbs;
> > +
> > +                       /** Excess Burst Size (EBS) (bytes). */
> > +                       uint64_t ebs;
> > +               } srtcm_pps;
> >         };
> >  };
> >
> > @@ -317,6 +332,13 @@ struct rte_mtr_capabilities {
> >          */
> >         uint32_t meter_trtcm_rfc4115_n_max;
> >
> > +       /** Maximum number of MTR objects that can have their meter
> > configured
> > +        * to run the srTCM packet per second algorithm. The value of 0
> > +        * indicates this metering algorithm is not supported.
> > +        * The maximum value is *n_max*.
> > +        */
> > +       uint32_t meter_srtcm_pps_n_max;
> > +
> >         /** Maximum traffic rate that can be metered by a single MTR
> > object. For
> >          * srTCM RFC 2697, this is the maximum CIR rate. For trTCM RFC
> > 2698,
> >          * this is the maximum PIR rate. For trTCM RFC 4115, this is
> > the maximum @@ -342,6 +364,12 @@ struct rte_mtr_capabilities {
> >          */
> >         int color_aware_trtcm_rfc4115_supported;
> >
> > +       /**
> > +       * When non-zero, it indicates that color aware mode is
> > + supported
> > for
> > +       * the srTCM packet per second  metering algorithm.
> > +       */
> > +       int color_aware_srtcm_pps_supported;
> > +
> >         /** When non-zero, it indicates that the policer packet
> > recolor actions
> >          * are supported.
> >          * @see enum rte_mtr_policer_action
> > --
> > 2.21.0
> >
> >

[dpdk-dev] [RFC v4 0/4] adds support PPS(packet per second) on meter

[Li Zhang]

Currently the flow Meter algorithms in rte_flow
only supports bytes per second(BPS).
Such as Single Rate Three Color Marker (srTCM rfc2697)
This RFC adds the packet per second definition in
Meter algorithms structure,
to support the rte_mtr APIs with type srTCM pps mode.
The below structure will be extended:
rte_mtr_algorithm
rte_mtr_meter_profile

v4:
* Fix the wrong commit log.

v3:
* Redefine the struct name for PPS mode.

v2:
* Rebase


Li Zhang (4):
  ethdev: add meter PPS profile
  common/mlx5: add meter mode definition in PRM file
  net/mlx5: support meter PPS profile
  app/testpmd: add meter pps mode cmd

 app/test-pmd/cmdline.c                        |   4 +
 app/test-pmd/cmdline_mtr.c                    | 105 ++++++++++++++++++
 app/test-pmd/cmdline_mtr.h                    |   1 +
 doc/guides/nics/mlx5.rst                      |   1 +
 .../traffic_metering_and_policing.rst         |   3 +-
 doc/guides/rel_notes/release_20_11.rst        |   5 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst   |  15 +++
 drivers/common/mlx5/mlx5_prm.h                |   8 ++
 drivers/net/mlx5/mlx5.h                       |  13 ++-
 drivers/net/mlx5/mlx5_flow_aso.c              |  17 ++-
 drivers/net/mlx5/mlx5_flow_meter.c            |  71 +++++++++---
 lib/librte_ethdev/rte_mtr.h                   |  32 ++++++
 12 files changed, 251 insertions(+), 24 deletions(-)

-- 
2.21.0

[dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile

[Li Zhang]

Currently meter algorithms only supports rate is bytes per second(BPS).
Add this new meter srTCMp algorithm to support rate is packet per second.
So that it can meter traffic by packet per second.
The below structure will be extended:
rte_mtr_algorithm
rte_mtr_meter_profile
Signed-off-by: Li Zhang <lizh@nvidia.com>
---
 .../traffic_metering_and_policing.rst         |  3 +-
 doc/guides/rel_notes/release_20_11.rst        |  5 +++
 lib/librte_ethdev/rte_mtr.h                   | 32 +++++++++++++++++++
 3 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/doc/guides/prog_guide/traffic_metering_and_policing.rst b/doc/guides/prog_guide/traffic_metering_and_policing.rst
index 90c781eb1d..4d2405d44a 100644
--- a/doc/guides/prog_guide/traffic_metering_and_policing.rst
+++ b/doc/guides/prog_guide/traffic_metering_and_policing.rst
@@ -17,7 +17,8 @@ The main features are:
 * Part of DPDK rte_ethdev API
 * Capability query API
 * Metering algorithms: RFC 2697 Single Rate Three Color Marker (srTCM), RFC 2698
-  and RFC 4115 Two Rate Three Color Marker (trTCM)
+  and RFC 4115 Two Rate Three Color Marker (trTCM),
+  Single Rate Three Color Marker, Packet based (srTCMp).
 * Policer actions (per meter output color): recolor, drop
 * Statistics (per policer output color)
 
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index 7405a9864f..de04886cc9 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -429,6 +429,11 @@ New Features
   can leverage IOAT DMA channels with vhost asynchronous APIs.
   See the :doc:`../sample_app_ug/vhost` for more details.
 
+* **Added support for meter PPS profile.**
+
+  Currently meter algorithms only supports bytes per second(BPS).
+  Add this new meter algorithm to support packet per second (PPS) mode.
+  So that it can meter traffic by packet per second.
 
 Removed Items
 -------------
diff --git a/lib/librte_ethdev/rte_mtr.h b/lib/librte_ethdev/rte_mtr.h
index 916a09c5c3..f27a4b5354 100644
--- a/lib/librte_ethdev/rte_mtr.h
+++ b/lib/librte_ethdev/rte_mtr.h
@@ -119,6 +119,11 @@ enum rte_mtr_algorithm {
 
 	/** Two Rate Three Color Marker (trTCM) - IETF RFC 4115. */
 	RTE_MTR_TRTCM_RFC4115,
+
+	/** Single Rate Three Color Marker, Packet based (srTCMp).
+	 * - - similar to IETF RFC 2697 but rate is packet per second.
+	 */
+	RTE_MTR_SRTCMP,
 };
 
 /**
@@ -171,6 +176,20 @@ struct rte_mtr_meter_profile {
 			/** Excess Burst Size (EBS) (bytes). */
 			uint64_t ebs;
 		} trtcm_rfc4115;
+
+		/** Items only valid when *alg* is set to srTCMp. */
+		struct {
+			/** Committed Information Rate (CIR)
+			 * (packets/second).
+			 */
+			uint64_t cir;
+
+			/** Committed Burst Size (CBS) (packets). */
+			uint64_t cbs;
+
+			/** Excess Burst Size (EBS) (packets). */
+			uint64_t ebs;
+		} srtcmp;
 	};
 };
 
@@ -317,6 +336,13 @@ struct rte_mtr_capabilities {
 	 */
 	uint32_t meter_trtcm_rfc4115_n_max;
 
+	/** Maximum number of MTR objects that can have their meter configured
+	 * to run the srTCMp algorithm. The value of 0
+	 * indicates this metering algorithm is not supported.
+	 * The maximum value is *n_max*.
+	 */
+	uint32_t meter_srtcmp_n_max;
+
 	/** Maximum traffic rate that can be metered by a single MTR object. For
 	 * srTCM RFC 2697, this is the maximum CIR rate. For trTCM RFC 2698,
 	 * this is the maximum PIR rate. For trTCM RFC 4115, this is the maximum
@@ -342,6 +368,12 @@ struct rte_mtr_capabilities {
 	 */
 	int color_aware_trtcm_rfc4115_supported;
 
+	/**
+	 * When non-zero, it indicates that color aware mode is supported for
+	 * the srTCMp metering algorithm.
+	 */
+	int color_aware_srtcmp_supported;
+
 	/** When non-zero, it indicates that the policer packet recolor actions
 	 * are supported.
 	 * @see enum rte_mtr_policer_action
-- 
2.21.0

Re: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile

[Dumitrescu, Cristian]

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Li Zhang
> Sent: Monday, March 1, 2021 10:35 AM
> To: dekelp@nvidia.com; orika@nvidia.com; viacheslavo@nvidia.com;
> matan@nvidia.com
> Cc: dev@dpdk.org; thomas@monjalon.net; rasland@nvidia.com;
> mb@smartsharesystems.com; ajit.khaparde@broadcom.com
> Subject: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile
> 
> Currently meter algorithms only supports rate is bytes per second(BPS).
> Add this new meter srTCMp algorithm to support rate is packet per second.
> So that it can meter traffic by packet per second.
> The below structure will be extended:
> rte_mtr_algorithm
> rte_mtr_meter_profile
> Signed-off-by: Li Zhang <lizh@nvidia.com>
> ---
>  .../traffic_metering_and_policing.rst         |  3 +-
>  doc/guides/rel_notes/release_20_11.rst        |  5 +++
>  lib/librte_ethdev/rte_mtr.h                   | 32 +++++++++++++++++++
>  3 files changed, 39 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/guides/prog_guide/traffic_metering_and_policing.rst
> b/doc/guides/prog_guide/traffic_metering_and_policing.rst
> index 90c781eb1d..4d2405d44a 100644
> --- a/doc/guides/prog_guide/traffic_metering_and_policing.rst
> +++ b/doc/guides/prog_guide/traffic_metering_and_policing.rst
> @@ -17,7 +17,8 @@ The main features are:
>  * Part of DPDK rte_ethdev API
>  * Capability query API
>  * Metering algorithms: RFC 2697 Single Rate Three Color Marker (srTCM),
> RFC 2698
> -  and RFC 4115 Two Rate Three Color Marker (trTCM)
> +  and RFC 4115 Two Rate Three Color Marker (trTCM),
> +  Single Rate Three Color Marker, Packet based (srTCMp).
>  * Policer actions (per meter output color): recolor, drop
>  * Statistics (per policer output color)
> 
> diff --git a/doc/guides/rel_notes/release_20_11.rst
> b/doc/guides/rel_notes/release_20_11.rst
> index 7405a9864f..de04886cc9 100644
> --- a/doc/guides/rel_notes/release_20_11.rst
> +++ b/doc/guides/rel_notes/release_20_11.rst
> @@ -429,6 +429,11 @@ New Features
>    can leverage IOAT DMA channels with vhost asynchronous APIs.
>    See the :doc:`../sample_app_ug/vhost` for more details.
> 
> +* **Added support for meter PPS profile.**
> +
> +  Currently meter algorithms only supports bytes per second(BPS).
> +  Add this new meter algorithm to support packet per second (PPS) mode.
> +  So that it can meter traffic by packet per second.
> 
>  Removed Items
>  -------------
> diff --git a/lib/librte_ethdev/rte_mtr.h b/lib/librte_ethdev/rte_mtr.h
> index 916a09c5c3..f27a4b5354 100644
> --- a/lib/librte_ethdev/rte_mtr.h
> +++ b/lib/librte_ethdev/rte_mtr.h
> @@ -119,6 +119,11 @@ enum rte_mtr_algorithm {
> 
>  	/** Two Rate Three Color Marker (trTCM) - IETF RFC 4115. */
>  	RTE_MTR_TRTCM_RFC4115,
> +
> +	/** Single Rate Three Color Marker, Packet based (srTCMp).
> +	 * - - similar to IETF RFC 2697 but rate is packet per second.
> +	 */
> +	RTE_MTR_SRTCMP,
>  };
> 
>  /**
> @@ -171,6 +176,20 @@ struct rte_mtr_meter_profile {
>  			/** Excess Burst Size (EBS) (bytes). */
>  			uint64_t ebs;
>  		} trtcm_rfc4115;
> +
> +		/** Items only valid when *alg* is set to srTCMp. */
> +		struct {
> +			/** Committed Information Rate (CIR)
> +			 * (packets/second).
> +			 */
> +			uint64_t cir;
> +
> +			/** Committed Burst Size (CBS) (packets). */
> +			uint64_t cbs;
> +
> +			/** Excess Burst Size (EBS) (packets). */
> +			uint64_t ebs;
> +		} srtcmp;
>  	};
>  };
> 
> @@ -317,6 +336,13 @@ struct rte_mtr_capabilities {
>  	 */
>  	uint32_t meter_trtcm_rfc4115_n_max;
> 
> +	/** Maximum number of MTR objects that can have their meter
> configured
> +	 * to run the srTCMp algorithm. The value of 0
> +	 * indicates this metering algorithm is not supported.
> +	 * The maximum value is *n_max*.
> +	 */
> +	uint32_t meter_srtcmp_n_max;
> +
>  	/** Maximum traffic rate that can be metered by a single MTR
> object. For
>  	 * srTCM RFC 2697, this is the maximum CIR rate. For trTCM RFC 2698,
>  	 * this is the maximum PIR rate. For trTCM RFC 4115, this is the
> maximum
> @@ -342,6 +368,12 @@ struct rte_mtr_capabilities {
>  	 */
>  	int color_aware_trtcm_rfc4115_supported;
> 
> +	/**
> +	 * When non-zero, it indicates that color aware mode is supported
> for
> +	 * the srTCMp metering algorithm.
> +	 */
> +	int color_aware_srtcmp_supported;
> +
>  	/** When non-zero, it indicates that the policer packet recolor
> actions
>  	 * are supported.
>  	 * @see enum rte_mtr_policer_action
> --
> 2.21.0

Hi Li,

As specified in the MAINTEINERS file of DPDK, I am the maintainer of this API, so please make sure you add my email in the To: list of future revisions of this patch set.

Isn't this a duplicate of this other patchset that you authored as well: http://patchwork.dpdk.org/project/dpdk/patch/20210301094000.183002-2-lizh@nvidia.com/ ? Which one do you want to keep? I am pasting below my reply to this other patchset.

We had this same problem earlier for the rte_tm.h API, where people asked to add support for WRED and shaper rates specified in packets to the existing byte rate support. I am more than happy to support adding the same here, but please let's adopt the same solution here rather than invent a different approach.

Please refer to struct rte_tm_wred_params and struct rte_tm_shaper_params from rte_tm.h: the packets vs. bytes mode is explicitly specified through the use of a flag called packet_mode that is added to the WRED and shaper profile. When packet_mode is 0, the profile rates and bucket sizes are specified in bytes per second and bytes, respectively; when packet_mode is not 0, the profile rates and bucket sizes are specified in packets and packets per second, respectively. The same profile parameters are used, no need to invent additional algorithms (such as srTCM - packet mode) or profile data structures. Can we do the same here, please?

This is a quick summary of the required API changes to add support for the packet mode, they are minimal:
a) Introduce the packet_mode flag in the profile parameters data structure.
b) Change the description (comment) of the rate and bucket size parameters in the meter profile parameters data structures to reflect that their values represents either bytes or packets, depending on the value of the new flag packet_mode from the same structure.
c) Add the relevant capabilities: just search for "packet" in the rte_tm.h capabilities data structures and apply the same to the rte_mtr.h capabilities, when applicable.

Regards,
Cristian

Re: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile

[Thomas Monjalon]

01/03/2021 14:20, Dumitrescu, Cristian:
> From: Li Zhang
> > As specified in the MAINTEINERS file of DPDK, I am the maintainer of this API, so please make sure you add my email in the To: list of future revisions of this patch set.

This kind of miss should be solved by using
--cc-cmd devtools/get-maintainer.sh when sending.

Re: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile

[Li Zhang]

Thanks Thomas.
I will use it next time.

Regards,
Li Zhang
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Thomas Monjalon
> Sent: Monday, March 1, 2021 11:54 PM
> To: Li Zhang <lizh@nvidia.com>
> Cc: Dekel Peled <dekelp@nvidia.com>; Ori Kam <orika@nvidia.com>; Slava
> Ovsiienko <viacheslavo@nvidia.com>; Matan Azrad <matan@nvidia.com>;
> Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; dev@dpdk.org; Raslan
> Darawsheh <rasland@nvidia.com>; mb@smartsharesystems.com;
> ajit.khaparde@broadcom.com; Yigit, Ferruh <ferruh.yigit@intel.com>; Singh,
> Jasvinder <jasvinder.singh@intel.com>
> Subject: Re: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile
> 
> 01/03/2021 14:20, Dumitrescu, Cristian:
> > From: Li Zhang
> > > As specified in the MAINTEINERS file of DPDK, I am the maintainer of this
> API, so please make sure you add my email in the To: list of future revisions of
> this patch set.
> 
> This kind of miss should be solved by using --cc-cmd devtools/get-
> maintainer.sh when sending.
> 
> 

Re: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile

[Ajit Khaparde]

[-- Attachment #1: Type: text/plain, Size: 7410 bytes --]

On Mon, Mar 1, 2021 at 5:20 AM Dumitrescu, Cristian
<cristian.dumitrescu@intel.com> wrote:
>
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Li Zhang
> > Sent: Monday, March 1, 2021 10:35 AM
> > To: dekelp@nvidia.com; orika@nvidia.com; viacheslavo@nvidia.com;
> > matan@nvidia.com
> > Cc: dev@dpdk.org; thomas@monjalon.net; rasland@nvidia.com;
> > mb@smartsharesystems.com; ajit.khaparde@broadcom.com
> > Subject: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile
> >
> > Currently meter algorithms only supports rate is bytes per second(BPS).
> > Add this new meter srTCMp algorithm to support rate is packet per second.
> > So that it can meter traffic by packet per second.
> > The below structure will be extended:
> > rte_mtr_algorithm
> > rte_mtr_meter_profile
> > Signed-off-by: Li Zhang <lizh@nvidia.com>
> > ---
> >  .../traffic_metering_and_policing.rst         |  3 +-
> >  doc/guides/rel_notes/release_20_11.rst        |  5 +++
> >  lib/librte_ethdev/rte_mtr.h                   | 32 +++++++++++++++++++
> >  3 files changed, 39 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/guides/prog_guide/traffic_metering_and_policing.rst
> > b/doc/guides/prog_guide/traffic_metering_and_policing.rst
> > index 90c781eb1d..4d2405d44a 100644
> > --- a/doc/guides/prog_guide/traffic_metering_and_policing.rst
> > +++ b/doc/guides/prog_guide/traffic_metering_and_policing.rst
> > @@ -17,7 +17,8 @@ The main features are:
> >  * Part of DPDK rte_ethdev API
> >  * Capability query API
> >  * Metering algorithms: RFC 2697 Single Rate Three Color Marker (srTCM),
> > RFC 2698
> > -  and RFC 4115 Two Rate Three Color Marker (trTCM)
> > +  and RFC 4115 Two Rate Three Color Marker (trTCM),
> > +  Single Rate Three Color Marker, Packet based (srTCMp).
> >  * Policer actions (per meter output color): recolor, drop
> >  * Statistics (per policer output color)
> >
> > diff --git a/doc/guides/rel_notes/release_20_11.rst
> > b/doc/guides/rel_notes/release_20_11.rst
> > index 7405a9864f..de04886cc9 100644
> > --- a/doc/guides/rel_notes/release_20_11.rst
> > +++ b/doc/guides/rel_notes/release_20_11.rst
> > @@ -429,6 +429,11 @@ New Features
> >    can leverage IOAT DMA channels with vhost asynchronous APIs.
> >    See the :doc:`../sample_app_ug/vhost` for more details.
> >
> > +* **Added support for meter PPS profile.**
> > +
> > +  Currently meter algorithms only supports bytes per second(BPS).
> > +  Add this new meter algorithm to support packet per second (PPS) mode.
> > +  So that it can meter traffic by packet per second.
> >
> >  Removed Items
> >  -------------
> > diff --git a/lib/librte_ethdev/rte_mtr.h b/lib/librte_ethdev/rte_mtr.h
> > index 916a09c5c3..f27a4b5354 100644
> > --- a/lib/librte_ethdev/rte_mtr.h
> > +++ b/lib/librte_ethdev/rte_mtr.h
> > @@ -119,6 +119,11 @@ enum rte_mtr_algorithm {
> >
> >       /** Two Rate Three Color Marker (trTCM) - IETF RFC 4115. */
> >       RTE_MTR_TRTCM_RFC4115,
> > +
> > +     /** Single Rate Three Color Marker, Packet based (srTCMp).
> > +      * - - similar to IETF RFC 2697 but rate is packet per second.
> > +      */
> > +     RTE_MTR_SRTCMP,
> >  };
> >
> >  /**
> > @@ -171,6 +176,20 @@ struct rte_mtr_meter_profile {
> >                       /** Excess Burst Size (EBS) (bytes). */
> >                       uint64_t ebs;
> >               } trtcm_rfc4115;
> > +
> > +             /** Items only valid when *alg* is set to srTCMp. */
> > +             struct {
> > +                     /** Committed Information Rate (CIR)
> > +                      * (packets/second).
> > +                      */
> > +                     uint64_t cir;
> > +
> > +                     /** Committed Burst Size (CBS) (packets). */
> > +                     uint64_t cbs;
> > +
> > +                     /** Excess Burst Size (EBS) (packets). */
> > +                     uint64_t ebs;
> > +             } srtcmp;
> >       };
> >  };
> >
> > @@ -317,6 +336,13 @@ struct rte_mtr_capabilities {
> >        */
> >       uint32_t meter_trtcm_rfc4115_n_max;
> >
> > +     /** Maximum number of MTR objects that can have their meter
> > configured
> > +      * to run the srTCMp algorithm. The value of 0
> > +      * indicates this metering algorithm is not supported.
> > +      * The maximum value is *n_max*.
> > +      */
> > +     uint32_t meter_srtcmp_n_max;
> > +
> >       /** Maximum traffic rate that can be metered by a single MTR
> > object. For
> >        * srTCM RFC 2697, this is the maximum CIR rate. For trTCM RFC 2698,
> >        * this is the maximum PIR rate. For trTCM RFC 4115, this is the
> > maximum
> > @@ -342,6 +368,12 @@ struct rte_mtr_capabilities {
> >        */
> >       int color_aware_trtcm_rfc4115_supported;
> >
> > +     /**
> > +      * When non-zero, it indicates that color aware mode is supported
> > for
> > +      * the srTCMp metering algorithm.
> > +      */
> > +     int color_aware_srtcmp_supported;
> > +
> >       /** When non-zero, it indicates that the policer packet recolor
> > actions
> >        * are supported.
> >        * @see enum rte_mtr_policer_action
> > --
> > 2.21.0
>
> Hi Li,
>
> As specified in the MAINTEINERS file of DPDK, I am the maintainer of this API, so please make sure you add my email in the To: list of future revisions of this patch set.
>
> Isn't this a duplicate of this other patchset that you authored as well: http://patchwork.dpdk.org/project/dpdk/patch/20210301094000.183002-2-lizh@nvidia.com/ ? Which one do you want to keep? I am pasting below my reply to this other patchset.
>
> We had this same problem earlier for the rte_tm.h API, where people asked to add support for WRED and shaper rates specified in packets to the existing byte rate support. I am more than happy to support adding the same here, but please let's adopt the same solution here rather than invent a different approach.
>
> Please refer to struct rte_tm_wred_params and struct rte_tm_shaper_params from rte_tm.h: the packets vs. bytes mode is explicitly specified through the use of a flag called packet_mode that is added to the WRED and shaper profile. When packet_mode is 0, the profile rates and bucket sizes are specified in bytes per second and bytes, respectively; when packet_mode is not 0, the profile rates and bucket sizes are specified in packets and packets per second, respectively. The same profile parameters are used, no need to invent additional algorithms (such as srTCM - packet mode) or profile data structures. Can we do the same here, please?
>
> This is a quick summary of the required API changes to add support for the packet mode, they are minimal:
> a) Introduce the packet_mode flag in the profile parameters data structure.
> b) Change the description (comment) of the rate and bucket size parameters in the meter profile parameters data structures to reflect that their values represents either bytes or packets, depending on the value of the new flag packet_mode from the same structure.
> c) Add the relevant capabilities: just search for "packet" in the rte_tm.h capabilities data structures and apply the same to the rte_mtr.h capabilities, when applicable.
Overall I think this is a better approach. And default packet_mode
will be bytes.


>
> Regards,
> Cristian

Re: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile

[Dumitrescu, Cristian]

<snip>...

> Overall I think this is a better approach. And default packet_mode
> will be bytes.
> 

Yes, agreed.

Re: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile

[Matan Azrad]

Hi Cristian

Thank you for review, please see inline.

From: Dumitrescu, Cristian
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Li Zhang
<snip>
> We had this same problem earlier for the rte_tm.h API, where people asked to
> add support for WRED and shaper rates specified in packets to the existing byte
> rate support. I am more than happy to support adding the same here, but
> please let's adopt the same solution here rather than invent a different
> approach.
> 
> Please refer to struct rte_tm_wred_params and struct rte_tm_shaper_params
> from rte_tm.h: the packets vs. bytes mode is explicitly specified through the use
> of a flag called packet_mode that is added to the WRED and shaper profile.
> When packet_mode is 0, the profile rates and bucket sizes are specified in
> bytes per second and bytes, respectively; when packet_mode is not 0, the
> profile rates and bucket sizes are specified in packets and packets per second,
> respectively. The same profile parameters are used, no need to invent
> additional algorithms (such as srTCM - packet mode) or profile data structures.
> Can we do the same here, please?

This flag approach is very intuitive suggestion and it has advantages.

The main problem with the flag approach is that it breaks ABI and API.
The profile structure size is changed due to a new field - ABI breakage.
The user must initialize the flag with zero to get old behavior - API breakage. 
 
I don't see issues with Li suggestion, Do you think Li suggestion has critical issues?

> This is a quick summary of the required API changes to add support for the
> packet mode, they are minimal:
> a) Introduce the packet_mode flag in the profile parameters data structure.
> b) Change the description (comment) of the rate and bucket size parameters in
> the meter profile parameters data structures to reflect that their values
> represents either bytes or packets, depending on the value of the new flag
> packet_mode from the same structure.
> c) Add the relevant capabilities: just search for "packet" in the rte_tm.h
> capabilities data structures and apply the same to the rte_mtr.h capabilities,
> when applicable.
 
> Regards,
> Cristian

Re: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile

[Dumitrescu, Cristian]

Hi Matan,

> -----Original Message-----
> From: Matan Azrad <matan@nvidia.com>
> Sent: Tuesday, March 2, 2021 7:02 AM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Li Zhang
> <lizh@nvidia.com>; Dekel Peled <dekelp@nvidia.com>; Ori Kam
> <orika@nvidia.com>; Slava Ovsiienko <viacheslavo@nvidia.com>
> Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon
> <thomas@monjalon.net>; Raslan Darawsheh <rasland@nvidia.com>;
> mb@smartsharesystems.com; ajit.khaparde@broadcom.com; Yigit, Ferruh
> <ferruh.yigit@intel.com>; Singh, Jasvinder <jasvinder.singh@intel.com>
> Subject: RE: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile
> 
> 
> 
> Hi Cristian
> 
> Thank you for review, please see inline.
> 
> From: Dumitrescu, Cristian
> > > From: dev <dev-bounces@dpdk.org> On Behalf Of Li Zhang
> <snip>
> > We had this same problem earlier for the rte_tm.h API, where people
> asked to
> > add support for WRED and shaper rates specified in packets to the existing
> byte
> > rate support. I am more than happy to support adding the same here, but
> > please let's adopt the same solution here rather than invent a different
> > approach.
> >
> > Please refer to struct rte_tm_wred_params and struct
> rte_tm_shaper_params
> > from rte_tm.h: the packets vs. bytes mode is explicitly specified through
> the use
> > of a flag called packet_mode that is added to the WRED and shaper profile.
> > When packet_mode is 0, the profile rates and bucket sizes are specified in
> > bytes per second and bytes, respectively; when packet_mode is not 0, the
> > profile rates and bucket sizes are specified in packets and packets per
> second,
> > respectively. The same profile parameters are used, no need to invent
> > additional algorithms (such as srTCM - packet mode) or profile data
> structures.
> > Can we do the same here, please?
> 
> This flag approach is very intuitive suggestion and it has advantages.
> 
> The main problem with the flag approach is that it breaks ABI and API.
> The profile structure size is changed due to a new field - ABI breakage.
> The user must initialize the flag with zero to get old behavior - API breakage.
> 

The rte_mtr API is experimental, all the API functions are correctly marked with __rte_experimental in rte_mtr.h file, so we can safely change the API and the ABI breakage is not applicable here. Therefore, this problem does not exist, correct?

> I don't see issues with Li suggestion, Do you think Li suggestion has critical
> issues?

It is probably better to keep the rte_mtr and the rte_tm APIs aligned, it simplifies the code maintenance and improves the user experience, which always pays off in the long run. Both APIs configure token buckets in either packet mode or byte mode, and it is desirable to have them work in the same way. Also, I think we should avoid duplicating configuration data structures for to support essentially the same algorithms (such as srTCM or trTCM) if we can.

The flag proposal is actually reducing the amount of work that you guys need to do to implement your proposal. There is no negative impact to your proposal and no big change, right?

> 
> > This is a quick summary of the required API changes to add support for the
> > packet mode, they are minimal:
> > a) Introduce the packet_mode flag in the profile parameters data
> structure.
> > b) Change the description (comment) of the rate and bucket size
> parameters in
> > the meter profile parameters data structures to reflect that their values
> > represents either bytes or packets, depending on the value of the new flag
> > packet_mode from the same structure.
> > c) Add the relevant capabilities: just search for "packet" in the rte_tm.h
> > capabilities data structures and apply the same to the rte_mtr.h
> capabilities,
> > when applicable.
> 
> > Regards,
> > Cristian

Regards,
Cristian

Re: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile

[Matan Azrad]

HI Cristian

From: Dumitrescu, Cristian
> Hi Matan,
> 
> > -----Original Message-----
> > From: Matan Azrad <matan@nvidia.com>
> > Sent: Tuesday, March 2, 2021 7:02 AM
> > To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Li Zhang
> > <lizh@nvidia.com>; Dekel Peled <dekelp@nvidia.com>; Ori Kam
> > <orika@nvidia.com>; Slava Ovsiienko <viacheslavo@nvidia.com>
> > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon <thomas@monjalon.net>;
> > Raslan Darawsheh <rasland@nvidia.com>; mb@smartsharesystems.com;
> > ajit.khaparde@broadcom.com; Yigit, Ferruh <ferruh.yigit@intel.com>;
> > Singh, Jasvinder <jasvinder.singh@intel.com>
> > Subject: RE: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile
> >
> >
> >
> > Hi Cristian
> >
> > Thank you for review, please see inline.
> >
> > From: Dumitrescu, Cristian
> > > > From: dev <dev-bounces@dpdk.org> On Behalf Of Li Zhang
> > <snip>
> > > We had this same problem earlier for the rte_tm.h API, where people
> > asked to
> > > add support for WRED and shaper rates specified in packets to the
> > > existing
> > byte
> > > rate support. I am more than happy to support adding the same here,
> > > but please let's adopt the same solution here rather than invent a
> > > different approach.
> > >
> > > Please refer to struct rte_tm_wred_params and struct
> > rte_tm_shaper_params
> > > from rte_tm.h: the packets vs. bytes mode is explicitly specified
> > > through
> > the use
> > > of a flag called packet_mode that is added to the WRED and shaper profile.
> > > When packet_mode is 0, the profile rates and bucket sizes are
> > > specified in bytes per second and bytes, respectively; when
> > > packet_mode is not 0, the profile rates and bucket sizes are
> > > specified in packets and packets per
> > second,
> > > respectively. The same profile parameters are used, no need to
> > > invent additional algorithms (such as srTCM - packet mode) or
> > > profile data
> > structures.
> > > Can we do the same here, please?
> >
> > This flag approach is very intuitive suggestion and it has advantages.
> >
> > The main problem with the flag approach is that it breaks ABI and API.
> > The profile structure size is changed due to a new field - ABI breakage.
> > The user must initialize the flag with zero to get old behavior - API breakage.
> >
> 
> The rte_mtr API is experimental, all the API functions are correctly marked
> with __rte_experimental in rte_mtr.h file, so we can safely change the API and
> the ABI breakage is not applicable here. Therefore, this problem does not exist,
> correct?

Yes, but still meter is not new API and I know that a lot of user uses it for a long time.
Forcing them to change while we have good solution that don't force it, looks me problematic.
 

> > I don't see issues with Li suggestion, Do you think Li suggestion has
> > critical issues?
> 
> It is probably better to keep the rte_mtr and the rte_tm APIs aligned, it
> simplifies the code maintenance and improves the user experience, which
> always pays off in the long run. Both APIs configure token buckets in either
> packet mode or byte mode, and it is desirable to have them work in the same
> way. Also, I think we should avoid duplicating configuration data structures for
> to support essentially the same algorithms (such as srTCM or trTCM) if we can.
> 

Yes, but I don't think this motivation is critical.

> The flag proposal is actually reducing the amount of work that you guys need to
> do to implement your proposal. There is no negative impact to your proposal
> and no big change, right?

Yes you right, but the implementation effect is not our concern. 


> > > This is a quick summary of the required API changes to add support
> > > for the packet mode, they are minimal:
> > > a) Introduce the packet_mode flag in the profile parameters data
> > structure.
> > > b) Change the description (comment) of the rate and bucket size
> > parameters in
> > > the meter profile parameters data structures to reflect that their
> > > values represents either bytes or packets, depending on the value of
> > > the new flag packet_mode from the same structure.
> > > c) Add the relevant capabilities: just search for "packet" in the
> > > rte_tm.h capabilities data structures and apply the same to the
> > > rte_mtr.h
> > capabilities,
> > > when applicable.
> >
> > > Regards,
> > > Cristian
> 
> Regards,
> Cristian

Re: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile

[Dumitrescu, Cristian]

Hi Matan,

> -----Original Message-----
> From: Matan Azrad <matan@nvidia.com>
> Sent: Tuesday, March 2, 2021 12:37 PM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Li Zhang
> <lizh@nvidia.com>; Dekel Peled <dekelp@nvidia.com>; Ori Kam
> <orika@nvidia.com>; Slava Ovsiienko <viacheslavo@nvidia.com>
> Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon
> <thomas@monjalon.net>; Raslan Darawsheh <rasland@nvidia.com>;
> mb@smartsharesystems.com; ajit.khaparde@broadcom.com; Yigit, Ferruh
> <ferruh.yigit@intel.com>; Singh, Jasvinder <jasvinder.singh@intel.com>
> Subject: RE: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile
> 
> HI Cristian
> 
> From: Dumitrescu, Cristian
> > Hi Matan,
> >
> > > -----Original Message-----
> > > From: Matan Azrad <matan@nvidia.com>
> > > Sent: Tuesday, March 2, 2021 7:02 AM
> > > To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Li Zhang
> > > <lizh@nvidia.com>; Dekel Peled <dekelp@nvidia.com>; Ori Kam
> > > <orika@nvidia.com>; Slava Ovsiienko <viacheslavo@nvidia.com>
> > > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon
> <thomas@monjalon.net>;
> > > Raslan Darawsheh <rasland@nvidia.com>; mb@smartsharesystems.com;
> > > ajit.khaparde@broadcom.com; Yigit, Ferruh <ferruh.yigit@intel.com>;
> > > Singh, Jasvinder <jasvinder.singh@intel.com>
> > > Subject: RE: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile
> > >
> > >
> > >
> > > Hi Cristian
> > >
> > > Thank you for review, please see inline.
> > >
> > > From: Dumitrescu, Cristian
> > > > > From: dev <dev-bounces@dpdk.org> On Behalf Of Li Zhang
> > > <snip>
> > > > We had this same problem earlier for the rte_tm.h API, where people
> > > asked to
> > > > add support for WRED and shaper rates specified in packets to the
> > > > existing
> > > byte
> > > > rate support. I am more than happy to support adding the same here,
> > > > but please let's adopt the same solution here rather than invent a
> > > > different approach.
> > > >
> > > > Please refer to struct rte_tm_wred_params and struct
> > > rte_tm_shaper_params
> > > > from rte_tm.h: the packets vs. bytes mode is explicitly specified
> > > > through
> > > the use
> > > > of a flag called packet_mode that is added to the WRED and shaper
> profile.
> > > > When packet_mode is 0, the profile rates and bucket sizes are
> > > > specified in bytes per second and bytes, respectively; when
> > > > packet_mode is not 0, the profile rates and bucket sizes are
> > > > specified in packets and packets per
> > > second,
> > > > respectively. The same profile parameters are used, no need to
> > > > invent additional algorithms (such as srTCM - packet mode) or
> > > > profile data
> > > structures.
> > > > Can we do the same here, please?
> > >
> > > This flag approach is very intuitive suggestion and it has advantages.
> > >
> > > The main problem with the flag approach is that it breaks ABI and API.
> > > The profile structure size is changed due to a new field - ABI breakage.
> > > The user must initialize the flag with zero to get old behavior - API
> breakage.
> > >
> >
> > The rte_mtr API is experimental, all the API functions are correctly marked
> > with __rte_experimental in rte_mtr.h file, so we can safely change the API
> and
> > the ABI breakage is not applicable here. Therefore, this problem does not
> exist,
> > correct?
> 
> Yes, but still meter is not new API and I know that a lot of user uses it for a
> long time.
> Forcing them to change while we have good solution that don't force it, looks
> me problematic.
> 

Not really, only 3 drivers are currently implementing this API.

Even to these drivers, the required changes are none or extremely small: as Ajit was also noting, as the default value of 0 continues to represent the existing byte mode, all you have to do is make sure the new flag is set to zero in the profile params structure, which is already done implicitly in most places as this structure is initialized to all-zeros.

A simple search exercise for struct rte_mtr_meter_profile is all that is needed. You also agreed the flag approach is very intuitive, hence better and nicer, with no additional work needed for you, so why not do it?

> 
> > > I don't see issues with Li suggestion, Do you think Li suggestion has
> > > critical issues?
> >
> > It is probably better to keep the rte_mtr and the rte_tm APIs aligned, it
> > simplifies the code maintenance and improves the user experience, which
> > always pays off in the long run. Both APIs configure token buckets in either
> > packet mode or byte mode, and it is desirable to have them work in the
> same
> > way. Also, I think we should avoid duplicating configuration data structures
> for
> > to support essentially the same algorithms (such as srTCM or trTCM) if we
> can.
> >
> 
> Yes, but I don't think this motivation is critical.

I really disagree. As API maintainer, making every effort to keep the APIs clear and consistent is a critical task for me. We don't want to proliferate the API data structures and parameters if there is a good way to avoid it. Especially in cases like this, when the drivers are just beginning to pick up this (still experimental) API,  we have the rare chance to make things right and therefore we should do it. Please also keep in mind that, as more feature are added to the API, small corner cuts like this one that might not look like a big deal now, eventually come back as unnecessary complexity in the drivers themselves.

So, please, let's try to keep the quality of the APIs high.

> 
> > The flag proposal is actually reducing the amount of work that you guys
> need to
> > do to implement your proposal. There is no negative impact to your
> proposal
> > and no big change, right?
> 
> Yes you right, but the implementation effect is not our concern.
> 
> 
> > > > This is a quick summary of the required API changes to add support
> > > > for the packet mode, they are minimal:
> > > > a) Introduce the packet_mode flag in the profile parameters data
> > > structure.
> > > > b) Change the description (comment) of the rate and bucket size
> > > parameters in
> > > > the meter profile parameters data structures to reflect that their
> > > > values represents either bytes or packets, depending on the value of
> > > > the new flag packet_mode from the same structure.
> > > > c) Add the relevant capabilities: just search for "packet" in the
> > > > rte_tm.h capabilities data structures and apply the same to the
> > > > rte_mtr.h
> > > capabilities,
> > > > when applicable.
> > >
> > > > Regards,
> > > > Cristian
> >
> > Regards,
> > Cristian

Regards,
Cristian

Re: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile

[Matan Azrad]

Hi Cristian

Good discussion, thank you for that!

From: Dumitrescu, Cristian
> Hi Matan,
> 
> > -----Original Message-----
> > From: Matan Azrad <matan@nvidia.com>
> > Sent: Tuesday, March 2, 2021 12:37 PM
> > To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Li Zhang
> > <lizh@nvidia.com>; Dekel Peled <dekelp@nvidia.com>; Ori Kam
> > <orika@nvidia.com>; Slava Ovsiienko <viacheslavo@nvidia.com>
> > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon <thomas@monjalon.net>;
> > Raslan Darawsheh <rasland@nvidia.com>; mb@smartsharesystems.com;
> > ajit.khaparde@broadcom.com; Yigit, Ferruh <ferruh.yigit@intel.com>;
> > Singh, Jasvinder <jasvinder.singh@intel.com>
> > Subject: RE: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile
> >
> > HI Cristian
> >
> > From: Dumitrescu, Cristian
> > > Hi Matan,
> > >
> > > > -----Original Message-----
> > > > From: Matan Azrad <matan@nvidia.com>
> > > > Sent: Tuesday, March 2, 2021 7:02 AM
> > > > To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Li Zhang
> > > > <lizh@nvidia.com>; Dekel Peled <dekelp@nvidia.com>; Ori Kam
> > > > <orika@nvidia.com>; Slava Ovsiienko <viacheslavo@nvidia.com>
> > > > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon
> > <thomas@monjalon.net>;
> > > > Raslan Darawsheh <rasland@nvidia.com>; mb@smartsharesystems.com;
> > > > ajit.khaparde@broadcom.com; Yigit, Ferruh
> > > > <ferruh.yigit@intel.com>; Singh, Jasvinder
> > > > <jasvinder.singh@intel.com>
> > > > Subject: RE: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile
> > > >
> > > >
> > > >
> > > > Hi Cristian
> > > >
> > > > Thank you for review, please see inline.
> > > >
> > > > From: Dumitrescu, Cristian
> > > > > > From: dev <dev-bounces@dpdk.org> On Behalf Of Li Zhang
> > > > <snip>
> > > > > We had this same problem earlier for the rte_tm.h API, where
> > > > > people
> > > > asked to
> > > > > add support for WRED and shaper rates specified in packets to
> > > > > the existing
> > > > byte
> > > > > rate support. I am more than happy to support adding the same
> > > > > here, but please let's adopt the same solution here rather than
> > > > > invent a different approach.
> > > > >
> > > > > Please refer to struct rte_tm_wred_params and struct
> > > > rte_tm_shaper_params
> > > > > from rte_tm.h: the packets vs. bytes mode is explicitly
> > > > > specified through
> > > > the use
> > > > > of a flag called packet_mode that is added to the WRED and
> > > > > shaper
> > profile.
> > > > > When packet_mode is 0, the profile rates and bucket sizes are
> > > > > specified in bytes per second and bytes, respectively; when
> > > > > packet_mode is not 0, the profile rates and bucket sizes are
> > > > > specified in packets and packets per
> > > > second,
> > > > > respectively. The same profile parameters are used, no need to
> > > > > invent additional algorithms (such as srTCM - packet mode) or
> > > > > profile data
> > > > structures.
> > > > > Can we do the same here, please?
> > > >
> > > > This flag approach is very intuitive suggestion and it has advantages.
> > > >
> > > > The main problem with the flag approach is that it breaks ABI and API.
> > > > The profile structure size is changed due to a new field - ABI breakage.
> > > > The user must initialize the flag with zero to get old behavior -
> > > > API
> > breakage.
> > > >
> > >
> > > The rte_mtr API is experimental, all the API functions are correctly
> > > marked with __rte_experimental in rte_mtr.h file, so we can safely
> > > change the API
> > and
> > > the ABI breakage is not applicable here. Therefore, this problem
> > > does not
> > exist,
> > > correct?
> >
> > Yes, but still meter is not new API and I know that a lot of user uses
> > it for a long time.
> > Forcing them to change while we have good solution that don't force
> > it, looks me problematic.
> >
> 
> Not really, only 3 drivers are currently implementing this API.

The user is not the PMD, the PMDs are the providers.
I'm talking about all our customers, all the current DPDK based applications like OVS and others (I familiar with at least 4 ConnectX customer applications) which use the meter API and I'm sure there are more around the world.
  
> Even to these drivers, the required changes are none or extremely small: as Ajit
> was also noting, as the default value of 0 continues to represent the existing
> byte mode, all you have to do is make sure the new flag is set to zero in the
> profile params structure, which is already done implicitly in most places as this
> structure is initialized to all-zeros.

Are you sure all the world initialize the struct to 0? and also in this case, without new compilation, not all the struct will be zeroes(the old size is smaller). 

> A simple search exercise for struct rte_mtr_meter_profile is all that is needed.
> You also agreed the flag approach is very intuitive, hence better and nicer, with
> no additional work needed for you, so why not do it?

Do you understand that any current application that use the meter API must recompile the code of the application? Part of them also probably need to set the flag to 0....
Do you understand also the potential issues for the applications which are not aware to the change? Debug time, etc....

> > > > I don't see issues with Li suggestion, Do you think Li suggestion
> > > > has critical issues?
> > >
> > > It is probably better to keep the rte_mtr and the rte_tm APIs
> > > aligned, it simplifies the code maintenance and improves the user
> > > experience, which always pays off in the long run. Both APIs
> > > configure token buckets in either packet mode or byte mode, and it
> > > is desirable to have them work in the
> > same
> > > way. Also, I think we should avoid duplicating configuration data
> > > structures
> > for
> > > to support essentially the same algorithms (such as srTCM or trTCM)
> > > if we
> > can.
> > >
> >
> > Yes, but I don't think this motivation is critical.
> 
> I really disagree. As API maintainer, making every effort to keep the APIs clear
> and consistent is a critical task for me.

New pps profile is also clear and simple.

> We don't want to proliferate the API
> data structures and parameters if there is a good way to avoid it. Especially in
> cases like this, when the drivers are just beginning to pick up this (still
> experimental) API,  we have the rare chance to make things right and therefore
> we should do it. Please also keep in mind that, as more feature are added to
> the API, small corner cuts like this one that might not look like a big deal now,
> eventually come back as unnecessary complexity in the drivers themselves.

I don't see a complexity in the current suggestion.

> So, please, let's try to keep the quality of the APIs high.

Also by this way is high.


Look, the flag approach is also good and makes the job.
The two approaches are clear, simple and in high quality.
I don't care which one from the 2 to take but I want to be sure we are all understand the pros and cons.

If you understand my concern on flag approach and still insist to take the flag approach we will align.

And if we so, and we are going to break the API\ABI, we are going to introduce new meter policy API soon and there, breaking API can help, lets see in other discussion later.

One more point:
Currently, the meter_id is managed by the user, I think it is better to let the PMDs to manage the meter_id.

Searching the PMD meter handler inside the PMD is very expensive for the API call rate when the meter_id is managed by the user.

Same for profile_id.

Also all the rte_flow API including the shared action API taking the PMD management approach.

What do you think?

> > > The flag proposal is actually reducing the amount of work that you
> > > guys
> > need to
> > > do to implement your proposal. There is no negative impact to your
> > proposal
> > > and no big change, right?
> >
> > Yes you right, but the implementation effect is not our concern.
> >
> >
> > > > > This is a quick summary of the required API changes to add
> > > > > support for the packet mode, they are minimal:
> > > > > a) Introduce the packet_mode flag in the profile parameters data
> > > > structure.
> > > > > b) Change the description (comment) of the rate and bucket size
> > > > parameters in
> > > > > the meter profile parameters data structures to reflect that
> > > > > their values represents either bytes or packets, depending on
> > > > > the value of the new flag packet_mode from the same structure.
> > > > > c) Add the relevant capabilities: just search for "packet" in
> > > > > the rte_tm.h capabilities data structures and apply the same to
> > > > > the rte_mtr.h
> > > > capabilities,
> > > > > when applicable.
> > > >
> > > > > Regards,
> > > > > Cristian
> > >
> > > Regards,
> > > Cristian
> 
> Regards,
> Cristian

Re: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile

[Dumitrescu, Cristian]

Hi Matan,

> -----Original Message-----
> From: Matan Azrad <matan@nvidia.com>
> Sent: Tuesday, March 2, 2021 6:10 PM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Li Zhang
> <lizh@nvidia.com>; Dekel Peled <dekelp@nvidia.com>; Ori Kam
> <orika@nvidia.com>; Slava Ovsiienko <viacheslavo@nvidia.com>
> Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon
> <thomas@monjalon.net>; Raslan Darawsheh <rasland@nvidia.com>;
> mb@smartsharesystems.com; ajit.khaparde@broadcom.com; Yigit, Ferruh
> <ferruh.yigit@intel.com>; Singh, Jasvinder <jasvinder.singh@intel.com>
> Subject: RE: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile
> 
> Hi Cristian
> 
> Good discussion, thank you for that!
> 
> From: Dumitrescu, Cristian
> > Hi Matan,
> >
> > > -----Original Message-----
> > > From: Matan Azrad <matan@nvidia.com>
> > > Sent: Tuesday, March 2, 2021 12:37 PM
> > > To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Li Zhang
> > > <lizh@nvidia.com>; Dekel Peled <dekelp@nvidia.com>; Ori Kam
> > > <orika@nvidia.com>; Slava Ovsiienko <viacheslavo@nvidia.com>
> > > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon
> <thomas@monjalon.net>;
> > > Raslan Darawsheh <rasland@nvidia.com>; mb@smartsharesystems.com;
> > > ajit.khaparde@broadcom.com; Yigit, Ferruh <ferruh.yigit@intel.com>;
> > > Singh, Jasvinder <jasvinder.singh@intel.com>
> > > Subject: RE: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile
> > >
> > > HI Cristian
> > >
> > > From: Dumitrescu, Cristian
> > > > Hi Matan,
> > > >
> > > > > -----Original Message-----
> > > > > From: Matan Azrad <matan@nvidia.com>
> > > > > Sent: Tuesday, March 2, 2021 7:02 AM
> > > > > To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Li Zhang
> > > > > <lizh@nvidia.com>; Dekel Peled <dekelp@nvidia.com>; Ori Kam
> > > > > <orika@nvidia.com>; Slava Ovsiienko <viacheslavo@nvidia.com>
> > > > > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon
> > > <thomas@monjalon.net>;
> > > > > Raslan Darawsheh <rasland@nvidia.com>;
> mb@smartsharesystems.com;
> > > > > ajit.khaparde@broadcom.com; Yigit, Ferruh
> > > > > <ferruh.yigit@intel.com>; Singh, Jasvinder
> > > > > <jasvinder.singh@intel.com>
> > > > > Subject: RE: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile
> > > > >
> > > > >
> > > > >
> > > > > Hi Cristian
> > > > >
> > > > > Thank you for review, please see inline.
> > > > >
> > > > > From: Dumitrescu, Cristian
> > > > > > > From: dev <dev-bounces@dpdk.org> On Behalf Of Li Zhang
> > > > > <snip>
> > > > > > We had this same problem earlier for the rte_tm.h API, where
> > > > > > people
> > > > > asked to
> > > > > > add support for WRED and shaper rates specified in packets to
> > > > > > the existing
> > > > > byte
> > > > > > rate support. I am more than happy to support adding the same
> > > > > > here, but please let's adopt the same solution here rather than
> > > > > > invent a different approach.
> > > > > >
> > > > > > Please refer to struct rte_tm_wred_params and struct
> > > > > rte_tm_shaper_params
> > > > > > from rte_tm.h: the packets vs. bytes mode is explicitly
> > > > > > specified through
> > > > > the use
> > > > > > of a flag called packet_mode that is added to the WRED and
> > > > > > shaper
> > > profile.
> > > > > > When packet_mode is 0, the profile rates and bucket sizes are
> > > > > > specified in bytes per second and bytes, respectively; when
> > > > > > packet_mode is not 0, the profile rates and bucket sizes are
> > > > > > specified in packets and packets per
> > > > > second,
> > > > > > respectively. The same profile parameters are used, no need to
> > > > > > invent additional algorithms (such as srTCM - packet mode) or
> > > > > > profile data
> > > > > structures.
> > > > > > Can we do the same here, please?
> > > > >
> > > > > This flag approach is very intuitive suggestion and it has advantages.
> > > > >
> > > > > The main problem with the flag approach is that it breaks ABI and API.
> > > > > The profile structure size is changed due to a new field - ABI
> breakage.
> > > > > The user must initialize the flag with zero to get old behavior -
> > > > > API
> > > breakage.
> > > > >
> > > >
> > > > The rte_mtr API is experimental, all the API functions are correctly
> > > > marked with __rte_experimental in rte_mtr.h file, so we can safely
> > > > change the API
> > > and
> > > > the ABI breakage is not applicable here. Therefore, this problem
> > > > does not
> > > exist,
> > > > correct?
> > >
> > > Yes, but still meter is not new API and I know that a lot of user uses
> > > it for a long time.
> > > Forcing them to change while we have good solution that don't force
> > > it, looks me problematic.
> > >
> >
> > Not really, only 3 drivers are currently implementing this API.
> 
> The user is not the PMD, the PMDs are the providers.
> I'm talking about all our customers, all the current DPDK based applications
> like OVS and others (I familiar with at least 4 ConnectX customer applications)
> which use the meter API and I'm sure there are more around the world.
> 
> > Even to these drivers, the required changes are none or extremely small:
> as Ajit
> > was also noting, as the default value of 0 continues to represent the
> existing
> > byte mode, all you have to do is make sure the new flag is set to zero in the
> > profile params structure, which is already done implicitly in most places as
> this
> > structure is initialized to all-zeros.
> 
> Are you sure all the world initialize the struct to 0? and also in this case,
> without new compilation, not all the struct will be zeroes(the old size is
> smaller).
> 
> > A simple search exercise for struct rte_mtr_meter_profile is all that is
> needed.
> > You also agreed the flag approach is very intuitive, hence better and nicer,
> with
> > no additional work needed for you, so why not do it?
> 
> Do you understand that any current application that use the meter API must
> recompile the code of the application? Part of them also probably need to
> set the flag to 0....
> Do you understand also the potential issues for the applications which are
> not aware to the change? Debug time, etc....
> 
> > > > > I don't see issues with Li suggestion, Do you think Li suggestion
> > > > > has critical issues?
> > > >
> > > > It is probably better to keep the rte_mtr and the rte_tm APIs
> > > > aligned, it simplifies the code maintenance and improves the user
> > > > experience, which always pays off in the long run. Both APIs
> > > > configure token buckets in either packet mode or byte mode, and it
> > > > is desirable to have them work in the
> > > same
> > > > way. Also, I think we should avoid duplicating configuration data
> > > > structures
> > > for
> > > > to support essentially the same algorithms (such as srTCM or trTCM)
> > > > if we
> > > can.
> > > >
> > >
> > > Yes, but I don't think this motivation is critical.
> >
> > I really disagree. As API maintainer, making every effort to keep the APIs
> clear
> > and consistent is a critical task for me.
> 
> New pps profile is also clear and simple.
> 
> > We don't want to proliferate the API
> > data structures and parameters if there is a good way to avoid it. Especially
> in
> > cases like this, when the drivers are just beginning to pick up this (still
> > experimental) API,  we have the rare chance to make things right and
> therefore
> > we should do it. Please also keep in mind that, as more feature are added
> to
> > the API, small corner cuts like this one that might not look like a big deal
> now,
> > eventually come back as unnecessary complexity in the drivers themselves.
> 
> I don't see a complexity in the current suggestion.
> 
> > So, please, let's try to keep the quality of the APIs high.
> 
> Also by this way is high.
> 
> 
> Look, the flag approach is also good and makes the job.
> The two approaches are clear, simple and in high quality.
> I don't care which one from the 2 to take but I want to be sure we are all
> understand the pros and cons.
> 
> If you understand my concern on flag approach and still insist to take the flag
> approach we will align.

Yes, thanks for summarizing the pros and cons, I confirm that I do understand your concerns.

Yes, sorry to disappoint you, I still think the packet_mode based approach is better for the long run, as it keeps the APIs clean and consistent. We are not adding new algorithms here, we're just adding a new mode to an existing algorithm, so IMO we should not duplicate configuration data structures and proliferate the number of algorithms artificially.

Yes, I do realize that in some limited cases the users will have to explicitly set the new packet_mode flag to zero or one, in case they need to enable the packet mode, but I think this is an acceptable cost because: (A) This API is clearly marked as experimental; (B) It is better to take a small incremental hit now to keep the APIs in good order rather than taking a bit hit in a few years as more features are added in the wrong way and the APIs become unmanageable.

> 
> And if we so, and we are going to break the API\ABI, we are going to
> introduce new meter policy API soon and there, breaking API can help, lets
> see in other discussion later.
> 

Yes, as you point out API changes are unavoidable as new features are added, we have to manage the API evolution correctly.

> One more point:
> Currently, the meter_id is managed by the user, I think it is better to let the
> PMDs to manage the meter_id.
> 
> Searching the PMD meter handler inside the PMD is very expensive for the
> API call rate when the meter_id is managed by the user.
> 
> Same for profile_id.
> 
> Also all the rte_flow API including the shared action API taking the PMD
> management approach.
> 
> What do you think?
> 

Yes, we have carefully considered and discussed both approaches a few years back when the API was introduced, this is not done by accident :), there are pros and cons for each of them.

If the object IDs are generated by the driver (outputs of the API), then it is the user application that needs to keep track of them, which can be very painful. Basically, for each API object the user application needs to create its own wrapper to store this ID. We basically transfer this problem to the user app.

If the object IDs are generated by the user application (inputs into the API), then we simplify the application by removing and indirection layer. Yes, it is true that this indirection layer now moves into the driver, but we should try to make the life easier for the appl developers as opposed to us, the driver developers. This indirection layer in the driver can be made a bit smarter than just a slow "for" loop; the search operation can be made faster with a small bit of effort, such as keeping this list sorted based on the object ID, splitting this list into buckets (similar to a hash table), etc, right?

Having the user app provide the object ID is especially important in the case of rte_tm API, where we have to deal with a tree of nodes, with thousands of nodes for each level. Having the app to store and manages this tree of IDs is a really bad idea, as the user app needs to mirror the tree of nodes on its side for no real benefit. As an added benefit, the user can generate these IDs using a rule, such as: given the specific path through the tree, the value of the ID can be computed.

But again, as you also mention above, there is a list of pros and cons for every approach, no approach is perfect. We took this approach for the good reasons listed above.

> > > > The flag proposal is actually reducing the amount of work that you
> > > > guys
> > > need to
> > > > do to implement your proposal. There is no negative impact to your
> > > proposal
> > > > and no big change, right?
> > >
> > > Yes you right, but the implementation effect is not our concern.
> > >
> > >
> > > > > > This is a quick summary of the required API changes to add
> > > > > > support for the packet mode, they are minimal:
> > > > > > a) Introduce the packet_mode flag in the profile parameters data
> > > > > structure.
> > > > > > b) Change the description (comment) of the rate and bucket size
> > > > > parameters in
> > > > > > the meter profile parameters data structures to reflect that
> > > > > > their values represents either bytes or packets, depending on
> > > > > > the value of the new flag packet_mode from the same structure.
> > > > > > c) Add the relevant capabilities: just search for "packet" in
> > > > > > the rte_tm.h capabilities data structures and apply the same to
> > > > > > the rte_mtr.h
> > > > > capabilities,
> > > > > > when applicable.
> > > > >
> > > > > > Regards,
> > > > > > Cristian
> > > >
> > > > Regards,
> > > > Cristian
> >
> > Regards,
> > Cristian

Regards,
Cristian

Re: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile

[Matan Azrad]

Hi Cristian

From: Dumitrescu, Cristian
> Hi Matan,
> 
> > -----Original Message-----
> > From: Matan Azrad <matan@nvidia.com>
> > Sent: Tuesday, March 2, 2021 6:10 PM
> > To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Li Zhang
> > <lizh@nvidia.com>; Dekel Peled <dekelp@nvidia.com>; Ori Kam
> > <orika@nvidia.com>; Slava Ovsiienko <viacheslavo@nvidia.com>
> > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon <thomas@monjalon.net>;
> > Raslan Darawsheh <rasland@nvidia.com>; mb@smartsharesystems.com;
> > ajit.khaparde@broadcom.com; Yigit, Ferruh <ferruh.yigit@intel.com>;
> > Singh, Jasvinder <jasvinder.singh@intel.com>
> > Subject: RE: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile
> >
> > Hi Cristian
> >
> > Good discussion, thank you for that!
> >
> > From: Dumitrescu, Cristian
> > > Hi Matan,
> > >
> > > > -----Original Message-----
> > > > From: Matan Azrad <matan@nvidia.com>
> > > > Sent: Tuesday, March 2, 2021 12:37 PM
> > > > To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Li Zhang
> > > > <lizh@nvidia.com>; Dekel Peled <dekelp@nvidia.com>; Ori Kam
> > > > <orika@nvidia.com>; Slava Ovsiienko <viacheslavo@nvidia.com>
> > > > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon
> > <thomas@monjalon.net>;
> > > > Raslan Darawsheh <rasland@nvidia.com>; mb@smartsharesystems.com;
> > > > ajit.khaparde@broadcom.com; Yigit, Ferruh
> > > > <ferruh.yigit@intel.com>; Singh, Jasvinder
> > > > <jasvinder.singh@intel.com>
> > > > Subject: RE: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile
> > > >
> > > > HI Cristian
> > > >
> > > > From: Dumitrescu, Cristian
> > > > > Hi Matan,
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Matan Azrad <matan@nvidia.com>
> > > > > > Sent: Tuesday, March 2, 2021 7:02 AM
> > > > > > To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Li
> > > > > > Zhang <lizh@nvidia.com>; Dekel Peled <dekelp@nvidia.com>; Ori
> > > > > > Kam <orika@nvidia.com>; Slava Ovsiienko
> > > > > > <viacheslavo@nvidia.com>
> > > > > > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon
> > > > <thomas@monjalon.net>;
> > > > > > Raslan Darawsheh <rasland@nvidia.com>;
> > mb@smartsharesystems.com;
> > > > > > ajit.khaparde@broadcom.com; Yigit, Ferruh
> > > > > > <ferruh.yigit@intel.com>; Singh, Jasvinder
> > > > > > <jasvinder.singh@intel.com>
> > > > > > Subject: RE: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS
> > > > > > profile
> > > > > >
> > > > > >
> > > > > >
> > > > > > Hi Cristian
> > > > > >
> > > > > > Thank you for review, please see inline.
> > > > > >
> > > > > > From: Dumitrescu, Cristian
> > > > > > > > From: dev <dev-bounces@dpdk.org> On Behalf Of Li Zhang
> > > > > > <snip>
> > > > > > > We had this same problem earlier for the rte_tm.h API, where
> > > > > > > people
> > > > > > asked to
> > > > > > > add support for WRED and shaper rates specified in packets
> > > > > > > to the existing
> > > > > > byte
> > > > > > > rate support. I am more than happy to support adding the
> > > > > > > same here, but please let's adopt the same solution here
> > > > > > > rather than invent a different approach.
> > > > > > >
> > > > > > > Please refer to struct rte_tm_wred_params and struct
> > > > > > rte_tm_shaper_params
> > > > > > > from rte_tm.h: the packets vs. bytes mode is explicitly
> > > > > > > specified through
> > > > > > the use
> > > > > > > of a flag called packet_mode that is added to the WRED and
> > > > > > > shaper
> > > > profile.
> > > > > > > When packet_mode is 0, the profile rates and bucket sizes
> > > > > > > are specified in bytes per second and bytes, respectively;
> > > > > > > when packet_mode is not 0, the profile rates and bucket
> > > > > > > sizes are specified in packets and packets per
> > > > > > second,
> > > > > > > respectively. The same profile parameters are used, no need
> > > > > > > to invent additional algorithms (such as srTCM - packet
> > > > > > > mode) or profile data
> > > > > > structures.
> > > > > > > Can we do the same here, please?
> > > > > >
> > > > > > This flag approach is very intuitive suggestion and it has advantages.
> > > > > >
> > > > > > The main problem with the flag approach is that it breaks ABI and API.
> > > > > > The profile structure size is changed due to a new field - ABI
> > breakage.
> > > > > > The user must initialize the flag with zero to get old
> > > > > > behavior - API
> > > > breakage.
> > > > > >
> > > > >
> > > > > The rte_mtr API is experimental, all the API functions are
> > > > > correctly marked with __rte_experimental in rte_mtr.h file, so
> > > > > we can safely change the API
> > > > and
> > > > > the ABI breakage is not applicable here. Therefore, this problem
> > > > > does not
> > > > exist,
> > > > > correct?
> > > >
> > > > Yes, but still meter is not new API and I know that a lot of user
> > > > uses it for a long time.
> > > > Forcing them to change while we have good solution that don't
> > > > force it, looks me problematic.
> > > >
> > >
> > > Not really, only 3 drivers are currently implementing this API.
> >
> > The user is not the PMD, the PMDs are the providers.
> > I'm talking about all our customers, all the current DPDK based
> > applications like OVS and others (I familiar with at least 4 ConnectX
> > customer applications) which use the meter API and I'm sure there are more
> around the world.
> >
> > > Even to these drivers, the required changes are none or extremely small:
> > as Ajit
> > > was also noting, as the default value of 0 continues to represent
> > > the
> > existing
> > > byte mode, all you have to do is make sure the new flag is set to
> > > zero in the profile params structure, which is already done
> > > implicitly in most places as
> > this
> > > structure is initialized to all-zeros.
> >
> > Are you sure all the world initialize the struct to 0? and also in
> > this case, without new compilation, not all the struct will be
> > zeroes(the old size is smaller).
> >
> > > A simple search exercise for struct rte_mtr_meter_profile is all
> > > that is
> > needed.
> > > You also agreed the flag approach is very intuitive, hence better
> > > and nicer,
> > with
> > > no additional work needed for you, so why not do it?
> >
> > Do you understand that any current application that use the meter API
> > must recompile the code of the application? Part of them also probably
> > need to set the flag to 0....
> > Do you understand also the potential issues for the applications which
> > are not aware to the change? Debug time, etc....
> >
> > > > > > I don't see issues with Li suggestion, Do you think Li
> > > > > > suggestion has critical issues?
> > > > >
> > > > > It is probably better to keep the rte_mtr and the rte_tm APIs
> > > > > aligned, it simplifies the code maintenance and improves the
> > > > > user experience, which always pays off in the long run. Both
> > > > > APIs configure token buckets in either packet mode or byte mode,
> > > > > and it is desirable to have them work in the
> > > > same
> > > > > way. Also, I think we should avoid duplicating configuration
> > > > > data structures
> > > > for
> > > > > to support essentially the same algorithms (such as srTCM or
> > > > > trTCM) if we
> > > > can.
> > > > >
> > > >
> > > > Yes, but I don't think this motivation is critical.
> > >
> > > I really disagree. As API maintainer, making every effort to keep
> > > the APIs
> > clear
> > > and consistent is a critical task for me.
> >
> > New pps profile is also clear and simple.
> >
> > > We don't want to proliferate the API data structures and parameters
> > > if there is a good way to avoid it. Especially
> > in
> > > cases like this, when the drivers are just beginning to pick up this
> > > (still
> > > experimental) API,  we have the rare chance to make things right and
> > therefore
> > > we should do it. Please also keep in mind that, as more feature are
> > > added
> > to
> > > the API, small corner cuts like this one that might not look like a
> > > big deal
> > now,
> > > eventually come back as unnecessary complexity in the drivers themselves.
> >
> > I don't see a complexity in the current suggestion.
> >
> > > So, please, let's try to keep the quality of the APIs high.
> >
> > Also by this way is high.
> >
> >
> > Look, the flag approach is also good and makes the job.
> > The two approaches are clear, simple and in high quality.
> > I don't care which one from the 2 to take but I want to be sure we are
> > all understand the pros and cons.
> >
> > If you understand my concern on flag approach and still insist to take
> > the flag approach we will align.
> 
> Yes, thanks for summarizing the pros and cons, I confirm that I do understand
> your concerns.
> 
> Yes, sorry to disappoint you, I still think the packet_mode based approach is
> better for the long run, as it keeps the APIs clean and consistent. We are not
> adding new algorithms here, we're just adding a new mode to an existing
> algorithm, so IMO we should not duplicate configuration data structures and
> proliferate the number of algorithms artificially.

Actually, PPS meter is a new algorithm - you can see that current algorithms RFCs don't talk about PPS.

> Yes, I do realize that in some limited cases the users will have to explicitly set
> the new packet_mode flag to zero or one, in case they need to enable the
> packet mode, but I think this is an acceptable cost because: (A) This API is
> clearly marked as experimental; (B) It is better to take a small incremental hit
> now to keep the APIs in good order rather than taking a bit hit in a few years as
> more features are added in the wrong way and the APIs become
> unmanageable.

I don't think that the current suggestion is in wrong way.
In any case, you insist, we will align.

> > And if we so, and we are going to break the API\ABI, we are going to
> > introduce new meter policy API soon and there, breaking API can help,
> > lets see in other discussion later.
> >
> 
> Yes, as you point out API changes are unavoidable as new features are added,
> we have to manage the API evolution correctly.
> 
> > One more point:
> > Currently, the meter_id is managed by the user, I think it is better
> > to let the PMDs to manage the meter_id.
> >
> > Searching the PMD meter handler inside the PMD is very expensive for
> > the API call rate when the meter_id is managed by the user.
> >
> > Same for profile_id.
> >
> > Also all the rte_flow API including the shared action API taking the
> > PMD management approach.
> >
> > What do you think?
> >
> 
> Yes, we have carefully considered and discussed both approaches a few years
> back when the API was introduced, this is not done by accident :), there are
> pros and cons for each of them.
> 
> If the object IDs are generated by the driver (outputs of the API), then it is the
> user application that needs to keep track of them, which can be very painful.
> Basically, for each API object the user application needs to create its own
> wrapper to store this ID. We basically transfer this problem to the user app.

No exactly\not for all, the app gets the meter_id in the same time it decides it now.
 
> If the object IDs are generated by the user application (inputs into the API),
> then we simplify the application by removing and indirection layer. Yes, it is
> true that this indirection layer now moves into the driver, but we should try to
> make the life easier for the appl developers as opposed to us, the driver
> developers. This indirection layer in the driver can be made a bit smarter than
> just a slow "for" loop; the search operation can be made faster with a small bit
> of effort, such as keeping this list sorted based on the object ID, splitting this list
> into buckets (similar to a hash table), etc, right?

Yes, there are even better solution than hash table from "rate" perspective.

But any solution costs a lot of memory just for this mapping...
When we talked about 4M meters supported(in mlx5 next release) it becomes an issue.  
 
> Having the user app provide the object ID is especially important in the case of
> rte_tm API, where we have to deal with a tree of nodes, with thousands of
> nodes for each level. Having the app to store and manages this tree of IDs is a
> really bad idea, as the user app needs to mirror the tree of nodes on its side for
> no real benefit. As an added benefit, the user can generate these IDs using a
> rule, such as: given the specific path through the tree, the value of the ID can
> be computed.

rte_tm is not rte_mtr - I think meter is different and used differently.
For example, as I know, no one from our dpdk meter customers(at least 5) use TREEs for meter management. OVS, for example, just randomize some meter_id and don't care about it.

Also, all the rte_flow API basics works with PMD ID\handle management approach.

> But again, as you also mention above, there is a list of pros and cons for every
> approach, no approach is perfect. We took this approach for the good reasons
> listed above.

If you familiar with TREE usage with meter, maybe we can combined easily the two approaches in this topic,

meter_id argument can be by reference, if it 0 - PMD set it, if not PMD use it.

> > > > > The flag proposal is actually reducing the amount of work that
> > > > > you guys
> > > > need to
> > > > > do to implement your proposal. There is no negative impact to
> > > > > your
> > > > proposal
> > > > > and no big change, right?
> > > >
> > > > Yes you right, but the implementation effect is not our concern.
> > > >
> > > >
> > > > > > > This is a quick summary of the required API changes to add
> > > > > > > support for the packet mode, they are minimal:
> > > > > > > a) Introduce the packet_mode flag in the profile parameters
> > > > > > > data
> > > > > > structure.
> > > > > > > b) Change the description (comment) of the rate and bucket
> > > > > > > size
> > > > > > parameters in
> > > > > > > the meter profile parameters data structures to reflect that
> > > > > > > their values represents either bytes or packets, depending
> > > > > > > on the value of the new flag packet_mode from the same structure.
> > > > > > > c) Add the relevant capabilities: just search for "packet"
> > > > > > > in the rte_tm.h capabilities data structures and apply the
> > > > > > > same to the rte_mtr.h
> > > > > > capabilities,
> > > > > > > when applicable.
> > > > > >
> > > > > > > Regards,
> > > > > > > Cristian
> > > > >
> > > > > Regards,
> > > > > Cristian
> > >
> > > Regards,
> > > Cristian
> 
> Regards,
> Cristian

Re: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile

[Dumitrescu, Cristian]

> -----Original Message-----
> From: Matan Azrad <matan@nvidia.com>
> Sent: Thursday, March 4, 2021 6:34 AM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Li Zhang
> <lizh@nvidia.com>; Dekel Peled <dekelp@nvidia.com>; Ori Kam
> <orika@nvidia.com>; Slava Ovsiienko <viacheslavo@nvidia.com>
> Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon
> <thomas@monjalon.net>; Raslan Darawsheh <rasland@nvidia.com>;
> mb@smartsharesystems.com; ajit.khaparde@broadcom.com; Yigit, Ferruh
> <ferruh.yigit@intel.com>; Singh, Jasvinder <jasvinder.singh@intel.com>
> Subject: RE: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile
> 
> Hi Cristian
> 
> From: Dumitrescu, Cristian
> > Hi Matan,
> >
> > > -----Original Message-----
> > > From: Matan Azrad <matan@nvidia.com>
> > > Sent: Tuesday, March 2, 2021 6:10 PM
> > > To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Li Zhang
> > > <lizh@nvidia.com>; Dekel Peled <dekelp@nvidia.com>; Ori Kam
> > > <orika@nvidia.com>; Slava Ovsiienko <viacheslavo@nvidia.com>
> > > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon
> <thomas@monjalon.net>;
> > > Raslan Darawsheh <rasland@nvidia.com>; mb@smartsharesystems.com;
> > > ajit.khaparde@broadcom.com; Yigit, Ferruh <ferruh.yigit@intel.com>;
> > > Singh, Jasvinder <jasvinder.singh@intel.com>
> > > Subject: RE: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile
> > >
> > > Hi Cristian
> > >
> > > Good discussion, thank you for that!
> > >
> > > From: Dumitrescu, Cristian
> > > > Hi Matan,
> > > >
> > > > > -----Original Message-----
> > > > > From: Matan Azrad <matan@nvidia.com>
> > > > > Sent: Tuesday, March 2, 2021 12:37 PM
> > > > > To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Li Zhang
> > > > > <lizh@nvidia.com>; Dekel Peled <dekelp@nvidia.com>; Ori Kam
> > > > > <orika@nvidia.com>; Slava Ovsiienko <viacheslavo@nvidia.com>
> > > > > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon
> > > <thomas@monjalon.net>;
> > > > > Raslan Darawsheh <rasland@nvidia.com>;
> mb@smartsharesystems.com;
> > > > > ajit.khaparde@broadcom.com; Yigit, Ferruh
> > > > > <ferruh.yigit@intel.com>; Singh, Jasvinder
> > > > > <jasvinder.singh@intel.com>
> > > > > Subject: RE: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile
> > > > >
> > > > > HI Cristian
> > > > >
> > > > > From: Dumitrescu, Cristian
> > > > > > Hi Matan,
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Matan Azrad <matan@nvidia.com>
> > > > > > > Sent: Tuesday, March 2, 2021 7:02 AM
> > > > > > > To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Li
> > > > > > > Zhang <lizh@nvidia.com>; Dekel Peled <dekelp@nvidia.com>; Ori
> > > > > > > Kam <orika@nvidia.com>; Slava Ovsiienko
> > > > > > > <viacheslavo@nvidia.com>
> > > > > > > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon
> > > > > <thomas@monjalon.net>;
> > > > > > > Raslan Darawsheh <rasland@nvidia.com>;
> > > mb@smartsharesystems.com;
> > > > > > > ajit.khaparde@broadcom.com; Yigit, Ferruh
> > > > > > > <ferruh.yigit@intel.com>; Singh, Jasvinder
> > > > > > > <jasvinder.singh@intel.com>
> > > > > > > Subject: RE: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS
> > > > > > > profile
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Hi Cristian
> > > > > > >
> > > > > > > Thank you for review, please see inline.
> > > > > > >
> > > > > > > From: Dumitrescu, Cristian
> > > > > > > > > From: dev <dev-bounces@dpdk.org> On Behalf Of Li Zhang
> > > > > > > <snip>
> > > > > > > > We had this same problem earlier for the rte_tm.h API, where
> > > > > > > > people
> > > > > > > asked to
> > > > > > > > add support for WRED and shaper rates specified in packets
> > > > > > > > to the existing
> > > > > > > byte
> > > > > > > > rate support. I am more than happy to support adding the
> > > > > > > > same here, but please let's adopt the same solution here
> > > > > > > > rather than invent a different approach.
> > > > > > > >
> > > > > > > > Please refer to struct rte_tm_wred_params and struct
> > > > > > > rte_tm_shaper_params
> > > > > > > > from rte_tm.h: the packets vs. bytes mode is explicitly
> > > > > > > > specified through
> > > > > > > the use
> > > > > > > > of a flag called packet_mode that is added to the WRED and
> > > > > > > > shaper
> > > > > profile.
> > > > > > > > When packet_mode is 0, the profile rates and bucket sizes
> > > > > > > > are specified in bytes per second and bytes, respectively;
> > > > > > > > when packet_mode is not 0, the profile rates and bucket
> > > > > > > > sizes are specified in packets and packets per
> > > > > > > second,
> > > > > > > > respectively. The same profile parameters are used, no need
> > > > > > > > to invent additional algorithms (such as srTCM - packet
> > > > > > > > mode) or profile data
> > > > > > > structures.
> > > > > > > > Can we do the same here, please?
> > > > > > >
> > > > > > > This flag approach is very intuitive suggestion and it has
> advantages.
> > > > > > >
> > > > > > > The main problem with the flag approach is that it breaks ABI and
> API.
> > > > > > > The profile structure size is changed due to a new field - ABI
> > > breakage.
> > > > > > > The user must initialize the flag with zero to get old
> > > > > > > behavior - API
> > > > > breakage.
> > > > > > >
> > > > > >
> > > > > > The rte_mtr API is experimental, all the API functions are
> > > > > > correctly marked with __rte_experimental in rte_mtr.h file, so
> > > > > > we can safely change the API
> > > > > and
> > > > > > the ABI breakage is not applicable here. Therefore, this problem
> > > > > > does not
> > > > > exist,
> > > > > > correct?
> > > > >
> > > > > Yes, but still meter is not new API and I know that a lot of user
> > > > > uses it for a long time.
> > > > > Forcing them to change while we have good solution that don't
> > > > > force it, looks me problematic.
> > > > >
> > > >
> > > > Not really, only 3 drivers are currently implementing this API.
> > >
> > > The user is not the PMD, the PMDs are the providers.
> > > I'm talking about all our customers, all the current DPDK based
> > > applications like OVS and others (I familiar with at least 4 ConnectX
> > > customer applications) which use the meter API and I'm sure there are
> more
> > around the world.
> > >
> > > > Even to these drivers, the required changes are none or extremely
> small:
> > > as Ajit
> > > > was also noting, as the default value of 0 continues to represent
> > > > the
> > > existing
> > > > byte mode, all you have to do is make sure the new flag is set to
> > > > zero in the profile params structure, which is already done
> > > > implicitly in most places as
> > > this
> > > > structure is initialized to all-zeros.
> > >
> > > Are you sure all the world initialize the struct to 0? and also in
> > > this case, without new compilation, not all the struct will be
> > > zeroes(the old size is smaller).
> > >
> > > > A simple search exercise for struct rte_mtr_meter_profile is all
> > > > that is
> > > needed.
> > > > You also agreed the flag approach is very intuitive, hence better
> > > > and nicer,
> > > with
> > > > no additional work needed for you, so why not do it?
> > >
> > > Do you understand that any current application that use the meter API
> > > must recompile the code of the application? Part of them also probably
> > > need to set the flag to 0....
> > > Do you understand also the potential issues for the applications which
> > > are not aware to the change? Debug time, etc....
> > >
> > > > > > > I don't see issues with Li suggestion, Do you think Li
> > > > > > > suggestion has critical issues?
> > > > > >
> > > > > > It is probably better to keep the rte_mtr and the rte_tm APIs
> > > > > > aligned, it simplifies the code maintenance and improves the
> > > > > > user experience, which always pays off in the long run. Both
> > > > > > APIs configure token buckets in either packet mode or byte mode,
> > > > > > and it is desirable to have them work in the
> > > > > same
> > > > > > way. Also, I think we should avoid duplicating configuration
> > > > > > data structures
> > > > > for
> > > > > > to support essentially the same algorithms (such as srTCM or
> > > > > > trTCM) if we
> > > > > can.
> > > > > >
> > > > >
> > > > > Yes, but I don't think this motivation is critical.
> > > >
> > > > I really disagree. As API maintainer, making every effort to keep
> > > > the APIs
> > > clear
> > > > and consistent is a critical task for me.
> > >
> > > New pps profile is also clear and simple.
> > >
> > > > We don't want to proliferate the API data structures and parameters
> > > > if there is a good way to avoid it. Especially
> > > in
> > > > cases like this, when the drivers are just beginning to pick up this
> > > > (still
> > > > experimental) API,  we have the rare chance to make things right and
> > > therefore
> > > > we should do it. Please also keep in mind that, as more feature are
> > > > added
> > > to
> > > > the API, small corner cuts like this one that might not look like a
> > > > big deal
> > > now,
> > > > eventually come back as unnecessary complexity in the drivers
> themselves.
> > >
> > > I don't see a complexity in the current suggestion.
> > >
> > > > So, please, let's try to keep the quality of the APIs high.
> > >
> > > Also by this way is high.
> > >
> > >
> > > Look, the flag approach is also good and makes the job.
> > > The two approaches are clear, simple and in high quality.
> > > I don't care which one from the 2 to take but I want to be sure we are
> > > all understand the pros and cons.
> > >
> > > If you understand my concern on flag approach and still insist to take
> > > the flag approach we will align.
> >
> > Yes, thanks for summarizing the pros and cons, I confirm that I do
> understand
> > your concerns.
> >
> > Yes, sorry to disappoint you, I still think the packet_mode based approach
> is
> > better for the long run, as it keeps the APIs clean and consistent. We are
> not
> > adding new algorithms here, we're just adding a new mode to an existing
> > algorithm, so IMO we should not duplicate configuration data structures
> and
> > proliferate the number of algorithms artificially.
> 
> Actually, PPS meter is a new algorithm - you can see that current algorithms
> RFCs don't talk about PPS.
> 

Yes, I know, I implemented it in librte_meter, but still, it is the same algorithm with just a different measurement unit (packet instead of byte), that's why many people (and you included :) ) still refer to it as srTCM  - RFC 2697.

> > Yes, I do realize that in some limited cases the users will have to explicitly
> set
> > the new packet_mode flag to zero or one, in case they need to enable the
> > packet mode, but I think this is an acceptable cost because: (A) This API is
> > clearly marked as experimental; (B) It is better to take a small incremental
> hit
> > now to keep the APIs in good order rather than taking a bit hit in a few
> years as
> > more features are added in the wrong way and the APIs become
> > unmanageable.
> 
> I don't think that the current suggestion is in wrong way.
> In any case, you insist, we will align.
> 

Thank you.

> > > And if we so, and we are going to break the API\ABI, we are going to
> > > introduce new meter policy API soon and there, breaking API can help,
> > > lets see in other discussion later.
> > >
> >
> > Yes, as you point out API changes are unavoidable as new features are
> added,
> > we have to manage the API evolution correctly.
> >
> > > One more point:
> > > Currently, the meter_id is managed by the user, I think it is better
> > > to let the PMDs to manage the meter_id.
> > >
> > > Searching the PMD meter handler inside the PMD is very expensive for
> > > the API call rate when the meter_id is managed by the user.
> > >
> > > Same for profile_id.
> > >
> > > Also all the rte_flow API including the shared action API taking the
> > > PMD management approach.
> > >
> > > What do you think?
> > >
> >
> > Yes, we have carefully considered and discussed both approaches a few
> years
> > back when the API was introduced, this is not done by accident :), there are
> > pros and cons for each of them.
> >
> > If the object IDs are generated by the driver (outputs of the API), then it is
> the
> > user application that needs to keep track of them, which can be very
> painful.
> > Basically, for each API object the user application needs to create its own
> > wrapper to store this ID. We basically transfer this problem to the user app.
> 
> No exactly\not for all, the app gets the meter_id in the same time it decides
> it now.
> 
> > If the object IDs are generated by the user application (inputs into the API),
> > then we simplify the application by removing and indirection layer. Yes, it is
> > true that this indirection layer now moves into the driver, but we should try
> to
> > make the life easier for the appl developers as opposed to us, the driver
> > developers. This indirection layer in the driver can be made a bit smarter
> than
> > just a slow "for" loop; the search operation can be made faster with a small
> bit
> > of effort, such as keeping this list sorted based on the object ID, splitting
> this list
> > into buckets (similar to a hash table), etc, right?
> 
> Yes, there are even better solution than hash table from "rate" perspective.
> 

I'd be very interested to hear your proposals here.

> But any solution costs a lot of memory just for this mapping...
> When we talked about 4M meters supported(in mlx5 next release) it
> becomes an issue.
> 

I thought your concern was about the speed/rate of API calls, you are saying it is not speed but memory footprint??

I would imagine that a system that enables all the 4M meters is a big beast with the most powerful CPU on the planet and many dozens of gigabytes of RAM, so a few extra megabytes for some API layers is not a concern?

> > Having the user app provide the object ID is especially important in the case
> of
> > rte_tm API, where we have to deal with a tree of nodes, with thousands of
> > nodes for each level. Having the app to store and manages this tree of IDs
> is a
> > really bad idea, as the user app needs to mirror the tree of nodes on its
> side for
> > no real benefit. As an added benefit, the user can generate these IDs using
> a
> > rule, such as: given the specific path through the tree, the value of the ID
> can
> > be computed.
> 
> rte_tm is not rte_mtr - I think meter is different and used differently.
> For example, as I know, no one from our dpdk meter customers(at least 5)
> use TREEs for meter management. OVS, for example, just randomize some
> meter_id and don't care about it.
> 

What kinds of trees? I'd be very interested to hear some proposals to make this handle mapping faster.

> Also, all the rte_flow API basics works with PMD ID\handle management
> approach.
> 

Yes, I am not saying it is wrong, none of the approaches is wrong IMO.

> > But again, as you also mention above, there is a list of pros and cons for
> every
> > approach, no approach is perfect. We took this approach for the good
> reasons
> > listed above.
> 
> If you familiar with TREE usage with meter, maybe we can combined easily
> the two approaches in this topic,
> 
> meter_id argument can be by reference, if it 0 - PMD set it, if not PMD use it.
> 

It would be good if you could elaborate here a bit, just to make sure we are on the same page.

> > > > > > The flag proposal is actually reducing the amount of work that
> > > > > > you guys
> > > > > need to
> > > > > > do to implement your proposal. There is no negative impact to
> > > > > > your
> > > > > proposal
> > > > > > and no big change, right?
> > > > >
> > > > > Yes you right, but the implementation effect is not our concern.
> > > > >
> > > > >
> > > > > > > > This is a quick summary of the required API changes to add
> > > > > > > > support for the packet mode, they are minimal:
> > > > > > > > a) Introduce the packet_mode flag in the profile parameters
> > > > > > > > data
> > > > > > > structure.
> > > > > > > > b) Change the description (comment) of the rate and bucket
> > > > > > > > size
> > > > > > > parameters in
> > > > > > > > the meter profile parameters data structures to reflect that
> > > > > > > > their values represents either bytes or packets, depending
> > > > > > > > on the value of the new flag packet_mode from the same
> structure.
> > > > > > > > c) Add the relevant capabilities: just search for "packet"
> > > > > > > > in the rte_tm.h capabilities data structures and apply the
> > > > > > > > same to the rte_mtr.h
> > > > > > > capabilities,
> > > > > > > > when applicable.
> > > > > > >
> > > > > > > > Regards,
> > > > > > > > Cristian
> > > > > >
> > > > > > Regards,
> > > > > > Cristian
> > > >
> > > > Regards,
> > > > Cristian
> >
> > Regards,
> > Cristian

Regards,
Cristian

[dpdk-dev] [RFC v4 2/4] common/mlx5: add meter mode definition in PRM file

[Li Zhang]

Add meter mode definition in PRM file

Signed-off-by: Li Zhang <lizh@nvidia.com>
---
 drivers/common/mlx5/mlx5_prm.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/common/mlx5/mlx5_prm.h b/drivers/common/mlx5/mlx5_prm.h
index e3d4120849..609b1c3951 100644
--- a/drivers/common/mlx5/mlx5_prm.h
+++ b/drivers/common/mlx5/mlx5_prm.h
@@ -2177,6 +2177,13 @@ struct mlx5_ifc_flow_meter_parameters_bits {
 #define MLX5_IFC_FLOW_METER_PARAM_MASK UINT64_C(0x80FFFFFF)
 #define MLX5_IFC_FLOW_METER_DISABLE_CBS_CIR_VAL 0x14BF00C8
 
+enum {
+	MLX5_METER_MODE_IP_LEN = 0x0,
+	MLX5_METER_MODE_L2_LEN = 0x1,
+	MLX5_METER_MODE_L2_IPG_LEN = 0x2,
+	MLX5_METER_MODE_PKT = 0x3,
+};
+
 enum {
 	MLX5_CQE_SIZE_64B = 0x0,
 	MLX5_CQE_SIZE_128B = 0x1,
@@ -2508,6 +2515,7 @@ struct mlx5_aso_mtr_dseg {
 #define ASO_DSEG_VALID_OFFSET 31
 #define ASO_DSEG_BO_OFFSET 30
 #define ASO_DSEG_SC_OFFSET 28
+#define ASO_DSEG_MTR_MODE 24
 #define ASO_DSEG_CBS_EXP_OFFSET 24
 #define ASO_DSEG_CBS_MAN_OFFSET 16
 #define ASO_DSEG_CIR_EXP_MASK 0x1F
-- 
2.21.0

[dpdk-dev] [RFC v4 3/4] net/mlx5: support meter PPS profile

[Li Zhang]

Currently meter algorithms only supports bytes per second(BPS).
Such as Single Rate Three Color Marker (srTCM rfc2697)
Add this new meter srTCMp algorithm to support rate is packet per second.
So that it can meter traffic by packet per second (PPS).

Signed-off-by: Li Zhang <lizh@nvidia.com>
---
 doc/guides/nics/mlx5.rst           |  1 +
 drivers/net/mlx5/mlx5.h            | 13 ++++--
 drivers/net/mlx5/mlx5_flow_aso.c   | 17 ++++---
 drivers/net/mlx5/mlx5_flow_meter.c | 71 ++++++++++++++++++++++++------
 4 files changed, 79 insertions(+), 23 deletions(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index a390a4b53c..93f5c0e4d4 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -362,6 +362,7 @@ Limitations
   - Green color is not supported with drop action.
   - Yellow detection is not supported.
   - Red color must be with drop action.
+  - meter srTCMp algorithm is supported.
 
 Statistics
 ----------
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index 2790995dcc..16fa1b6c4d 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -742,8 +742,13 @@ struct mlx5_flow_meter_info {
 	/**< Flow meter action. */
 };
 
-/* RFC2697 parameter structure. */
-struct mlx5_flow_meter_srtcm_rfc2697_prm {
+/* PPS(packets per second) map to BPS(Bytes per second).
+ * HW treat packet as 128bytes in PPS mode
+ */
+#define MLX5_MTRS_PPS_MAP_BPS_SHIFT 7
+
+/* RFC2697/PPS parameter structure. */
+struct mlx5_flow_meter_srtcm_prm {
 	rte_be32_t cbs_cir;
 	/*
 	 * bit 24-28: cbs_exponent, bit 16-23 cbs_mantissa,
@@ -763,8 +768,8 @@ struct mlx5_flow_meter_profile {
 	uint32_t id; /**< Profile id. */
 	struct rte_mtr_meter_profile profile; /**< Profile detail. */
 	union {
-		struct mlx5_flow_meter_srtcm_rfc2697_prm srtcm_prm;
-		/**< srtcm_rfc2697 struct. */
+		struct mlx5_flow_meter_srtcm_prm srtcm_prm;
+		/**< srtcm_rfc2697/srtcm_pps struct. */
 	};
 	uint32_t ref_cnt; /**< Use count. */
 };
diff --git a/drivers/net/mlx5/mlx5_flow_aso.c b/drivers/net/mlx5/mlx5_flow_aso.c
index c9280b1f9d..3f3ba7e8fa 100644
--- a/drivers/net/mlx5/mlx5_flow_aso.c
+++ b/drivers/net/mlx5/mlx5_flow_aso.c
@@ -244,7 +244,6 @@ mlx5_aso_mtr_init_sq(struct mlx5_aso_sq *sq)
 	volatile struct mlx5_aso_wqe *restrict wqe;
 	int i;
 	int size = 1 << sq->log_desc_n;
-	uint32_t idx;
 
 	/* All the next fields state should stay constant. */
 	for (i = 0, wqe = &sq->wqes[0]; i < size; ++i, ++wqe) {
@@ -257,11 +256,6 @@ mlx5_aso_mtr_init_sq(struct mlx5_aso_sq *sq)
 			 (BYTEWISE_64BYTE << ASO_CSEG_DATA_MASK_MODE_OFFSET));
 		wqe->general_cseg.flags = RTE_BE32(MLX5_COMP_ALWAYS <<
 							 MLX5_COMP_MODE_OFFSET);
-		for (idx = 0; idx < MLX5_ASO_METERS_PER_WQE;
-			idx++)
-			wqe->aso_dseg.mtrs[idx].v_bo_sc_bbog_mm =
-				RTE_BE32((1 << ASO_DSEG_VALID_OFFSET) |
-				(MLX5_FLOW_COLOR_GREEN << ASO_DSEG_SC_OFFSET));
 	}
 }
 
@@ -744,6 +738,7 @@ mlx5_aso_mtr_sq_enqueue_single(struct mlx5_aso_sq *sq,
 {
 	volatile struct mlx5_aso_wqe *wqe = NULL;
 	struct mlx5_flow_meter_info *fm = NULL;
+	struct mlx5_flow_meter_profile *fmp;
 	uint16_t size = 1 << sq->log_desc_n;
 	uint16_t mask = size - 1;
 	uint16_t res = size - (uint16_t)(sq->head - sq->tail);
@@ -781,6 +776,16 @@ mlx5_aso_mtr_sq_enqueue_single(struct mlx5_aso_sq *sq,
 			RTE_BE32(MLX5_IFC_FLOW_METER_DISABLE_CBS_CIR_VAL);
 		wqe->aso_dseg.mtrs[dseg_idx].ebs_eir = 0;
 	}
+	fmp = fm->profile;
+	if (fmp->profile.alg == RTE_MTR_SRTCMP)
+		wqe->aso_dseg.mtrs[dseg_idx].v_bo_sc_bbog_mm =
+				RTE_BE32((1 << ASO_DSEG_VALID_OFFSET) |
+				(MLX5_FLOW_COLOR_GREEN << ASO_DSEG_SC_OFFSET) |
+				(MLX5_METER_MODE_PKT << ASO_DSEG_MTR_MODE));
+	else
+		wqe->aso_dseg.mtrs[dseg_idx].v_bo_sc_bbog_mm =
+				RTE_BE32((1 << ASO_DSEG_VALID_OFFSET) |
+				(MLX5_FLOW_COLOR_GREEN << ASO_DSEG_SC_OFFSET));
 	sq->head++;
 	sq->pi += 2;/* Each WQE contains 2 WQEBB's. */
 	rte_io_wmb();
diff --git a/drivers/net/mlx5/mlx5_flow_meter.c b/drivers/net/mlx5/mlx5_flow_meter.c
index 49f6229ae6..cf2fe8c173 100644
--- a/drivers/net/mlx5/mlx5_flow_meter.c
+++ b/drivers/net/mlx5/mlx5_flow_meter.c
@@ -33,7 +33,7 @@ mlx5_flow_meter_action_create(struct mlx5_priv *priv,
 #ifdef HAVE_MLX5_DR_CREATE_ACTION_FLOW_METER
 	struct mlx5dv_dr_flow_meter_attr mtr_init;
 	uint32_t fmp[MLX5_ST_SZ_DW(flow_meter_parameters)];
-	struct mlx5_flow_meter_srtcm_rfc2697_prm *srtcm =
+	struct mlx5_flow_meter_srtcm_prm *srtcm =
 						     &fm->profile->srtcm_prm;
 	uint32_t cbs_cir = rte_be_to_cpu_32(srtcm->cbs_cir);
 	uint32_t ebs_eir = rte_be_to_cpu_32(srtcm->ebs_eir);
@@ -157,6 +157,32 @@ mlx5_flow_meter_profile_validate(struct rte_eth_dev *dev,
 					      "Invalid metering parameters.");
 		}
 	}
+	if (priv->sh->meter_aso_en &&
+		profile->alg == RTE_MTR_SRTCMP) {
+		if (priv->config.hca_attr.qos.srtcm_sup) {
+			/* Verify support for flow meter parameters. */
+			if (profile->srtcmp.cir > 0 &&
+			    (profile->srtcmp.cir <<
+					MLX5_MTRS_PPS_MAP_BPS_SHIFT)
+						<= MLX5_SRTCM_CIR_MAX &&
+			    profile->srtcmp.cbs > 0 &&
+			    (profile->srtcmp.cbs <<
+					MLX5_MTRS_PPS_MAP_BPS_SHIFT)
+						<= MLX5_SRTCM_CBS_MAX &&
+			    (profile->srtcmp.ebs <<
+					MLX5_MTRS_PPS_MAP_BPS_SHIFT)
+						<= MLX5_SRTCM_EBS_MAX)
+				return 0;
+			else
+				return -rte_mtr_error_set
+					     (error, ENOTSUP,
+					      RTE_MTR_ERROR_TYPE_MTR_PARAMS,
+					      NULL,
+					      profile->srtcmp.ebs ?
+					      "Metering value ebs must be 0." :
+					      "Invalid metering parameters.");
+		}
+	}
 	return -rte_mtr_error_set(error, ENOTSUP,
 				  RTE_MTR_ERROR_TYPE_METER_PROFILE,
 				  NULL, "Metering algorithm not supported.");
@@ -238,19 +264,35 @@ 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 rte_mtr_error *error)
+			struct mlx5_priv *priv, struct rte_mtr_error *error)
 {
-	struct mlx5_flow_meter_srtcm_rfc2697_prm *srtcm = &fmp->srtcm_prm;
+	struct mlx5_flow_meter_srtcm_prm *srtcm = &fmp->srtcm_prm;
 	uint8_t man, exp;
 	uint32_t cbs_exp, cbs_man, cir_exp, cir_man;
 	uint32_t ebs_exp, ebs_man;
+	uint64_t cir, cbs, ebs;
 
-	if (fmp->profile.alg != RTE_MTR_SRTCM_RFC2697)
-		return -rte_mtr_error_set(error, ENOTSUP,
+	if (fmp->profile.alg == RTE_MTR_SRTCM_RFC2697) {
+		cir = fmp->profile.srtcm_rfc2697.cir;
+		cbs = fmp->profile.srtcm_rfc2697.cbs;
+		ebs = fmp->profile.srtcm_rfc2697.ebs;
+	} else {
+		if (priv->sh->meter_aso_en &&
+			fmp->profile.alg == RTE_MTR_SRTCMP) {
+			cir = fmp->profile.srtcmp.cir <<
+				MLX5_MTRS_PPS_MAP_BPS_SHIFT;
+			cbs = fmp->profile.srtcmp.cbs <<
+				MLX5_MTRS_PPS_MAP_BPS_SHIFT;
+			ebs = fmp->profile.srtcmp.ebs <<
+				MLX5_MTRS_PPS_MAP_BPS_SHIFT;
+		} else {
+			return -rte_mtr_error_set(error, ENOTSUP,
 				RTE_MTR_ERROR_TYPE_METER_PROFILE,
 				NULL, "Metering algorithm not supported.");
+		}
+	}
 	/* cir = 8G * cir_mantissa * 1/(2^cir_exponent)) Bytes/Sec */
-	mlx5_flow_meter_cir_man_exp_calc(fmp->profile.srtcm_rfc2697.cir,
+	mlx5_flow_meter_cir_man_exp_calc(cir,
 				    &man, &exp);
 	/* Check if cir mantissa is too large. */
 	if (exp > ASO_DSEG_CIR_EXP_MASK)
@@ -261,7 +303,7 @@ mlx5_flow_meter_param_fill(struct mlx5_flow_meter_profile *fmp,
 	cir_man = man;
 	cir_exp = exp;
 	 /* cbs = cbs_mantissa * 2^cbs_exponent */
-	mlx5_flow_meter_xbs_man_exp_calc(fmp->profile.srtcm_rfc2697.cbs,
+	mlx5_flow_meter_xbs_man_exp_calc(cbs,
 				    &man, &exp);
 	/* Check if cbs mantissa is too large. */
 	if (exp > ASO_DSEG_EXP_MASK)
@@ -275,7 +317,7 @@ mlx5_flow_meter_param_fill(struct mlx5_flow_meter_profile *fmp,
 				cbs_man << ASO_DSEG_CBS_MAN_OFFSET |
 				cir_exp << ASO_DSEG_CIR_EXP_OFFSET |
 				cir_man);
-	mlx5_flow_meter_xbs_man_exp_calc(fmp->profile.srtcm_rfc2697.ebs,
+	mlx5_flow_meter_xbs_man_exp_calc(ebs,
 				    &man, &exp);
 	/* Check if ebs mantissa is too large. */
 	if (exp > ASO_DSEG_EXP_MASK)
@@ -316,11 +358,14 @@ mlx5_flow_mtr_cap_get(struct rte_eth_dev *dev,
 					  RTE_MTR_ERROR_TYPE_UNSPECIFIED, NULL,
 					  "Meter is not supported");
 	memset(cap, 0, sizeof(*cap));
-	if (priv->sh->meter_aso_en)
+	if (priv->sh->meter_aso_en) {
 	    /* 2 meters per one ASO cache line. */
 		cap->n_max = 1 << (qattr->log_max_num_meter_aso + 1);
-	else
+		cap->meter_srtcmp_n_max = qattr->srtcm_sup ? cap->n_max : 0;
+	} else {
 		cap->n_max = 1 << qattr->log_max_flow_meter;
+		cap->meter_srtcmp_n_max = 0;
+	}
 	cap->n_shared_max = cap->n_max;
 	cap->identical = 1;
 	cap->shared_identical = 1;
@@ -382,7 +427,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, error);
+	ret = mlx5_flow_meter_param_fill(fmp, priv, error);
 	if (ret)
 		goto error;
 	/* Add to list. */
@@ -539,7 +584,7 @@ mlx5_flow_meter_validate(struct mlx5_priv *priv, uint32_t meter_id,
 static int
 mlx5_flow_meter_action_modify(struct mlx5_priv *priv,
 		struct mlx5_flow_meter_info *fm,
-		const struct mlx5_flow_meter_srtcm_rfc2697_prm *srtcm,
+		const struct mlx5_flow_meter_srtcm_prm *srtcm,
 		uint64_t modify_bits, uint32_t active_state, uint32_t is_enable)
 {
 #ifdef HAVE_MLX5_DR_CREATE_ACTION_FLOW_METER
@@ -899,7 +944,7 @@ mlx5_flow_meter_modify_state(struct mlx5_priv *priv,
 			     uint32_t new_state,
 			     struct rte_mtr_error *error)
 {
-	static const struct mlx5_flow_meter_srtcm_rfc2697_prm srtcm = {
+	static const struct mlx5_flow_meter_srtcm_prm srtcm = {
 		.cbs_cir = RTE_BE32(MLX5_IFC_FLOW_METER_DISABLE_CBS_CIR_VAL),
 		.ebs_eir = 0,
 	};
-- 
2.21.0

[dpdk-dev] [RFC v4 4/4] app/testpmd: add meter pps mode cmd

[Li Zhang]

Support meter pps mode

Signed-off-by: Li Zhang <lizh@nvidia.com>
---
 app/test-pmd/cmdline.c                      |   4 +
 app/test-pmd/cmdline_mtr.c                  | 105 ++++++++++++++++++++
 app/test-pmd/cmdline_mtr.h                  |   1 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  15 +++
 4 files changed, 125 insertions(+)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index d274a7cb8c..1a3fc644dc 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -698,6 +698,9 @@ static void cmd_help_long_parsed(void *parsed_result,
 			"add port meter profile trtcm_rfc4115 (port_id) (profile_id) (cir) (eir) (cbs) (ebs)\n"
 			"    meter profile add - trtcm rfc 4115\n\n"
 
+			"add port meter profile srtcmp (port_id) (profile_id) (cipr) (cpbs) (epbs)\n"
+			"    meter profile add - srtcmp packet per second\n\n"
+
 			"del port meter profile (port_id) (profile_id)\n"
 			"    meter profile delete\n\n"
 
@@ -17006,6 +17009,7 @@ cmdline_parse_ctx_t main_ctx[] = {
 	(cmdline_parse_inst_t *)&cmd_show_port_meter_cap,
 	(cmdline_parse_inst_t *)&cmd_add_port_meter_profile_srtcm,
 	(cmdline_parse_inst_t *)&cmd_add_port_meter_profile_trtcm,
+	(cmdline_parse_inst_t *)&cmd_add_port_meter_profile_srtcmp,
 	(cmdline_parse_inst_t *)&cmd_del_port_meter_profile,
 	(cmdline_parse_inst_t *)&cmd_create_port_meter,
 	(cmdline_parse_inst_t *)&cmd_enable_port_meter,
diff --git a/app/test-pmd/cmdline_mtr.c b/app/test-pmd/cmdline_mtr.c
index 399ee56e07..3f62240a0d 100644
--- a/app/test-pmd/cmdline_mtr.c
+++ b/app/test-pmd/cmdline_mtr.c
@@ -295,6 +295,8 @@ static void cmd_show_port_meter_cap_parsed(void *parsed_result,
 		cap.meter_trtcm_rfc2698_n_max);
 	printf("cap.meter_trtcm_rfc4115_n_max %" PRIu32 "\n",
 		cap.meter_trtcm_rfc4115_n_max);
+	printf("cap.meter_srtcmp_n_max %" PRIu32 "\n",
+		cap.meter_srtcmp_n_max);
 	printf("cap.meter_rate_max %" PRIu64 "\n", cap.meter_rate_max);
 	printf("cap.color_aware_srtcm_rfc2697_supported %" PRId32 "\n",
 		cap.color_aware_srtcm_rfc2697_supported);
@@ -302,6 +304,8 @@ static void cmd_show_port_meter_cap_parsed(void *parsed_result,
 		cap.color_aware_trtcm_rfc2698_supported);
 	printf("cap.color_aware_trtcm_rfc4115_supported %" PRId32 "\n",
 		cap.color_aware_trtcm_rfc4115_supported);
+	printf("cap.color_aware_srtcmp_supported %" PRId32 "\n",
+		cap.color_aware_srtcmp_supported);
 	printf("cap.policer_action_recolor_supported %" PRId32 "\n",
 		cap.policer_action_recolor_supported);
 	printf("cap.policer_action_drop_supported %" PRId32 "\n",
@@ -644,6 +648,107 @@ cmdline_parse_inst_t cmd_add_port_meter_profile_trtcm_rfc4115 = {
 	},
 };
 
+/* *** Add Port Meter Profile srtcmp *** */
+struct cmd_add_port_meter_profile_srtcmp_result {
+	cmdline_fixed_string_t add;
+	cmdline_fixed_string_t port;
+	cmdline_fixed_string_t meter;
+	cmdline_fixed_string_t profile;
+	cmdline_fixed_string_t srtcmp;
+	uint16_t port_id;
+	uint32_t profile_id;
+	uint64_t cir;
+	uint64_t cbs;
+	uint64_t ebs;
+};
+
+cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcmp_add =
+	TOKEN_STRING_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result, add, "add");
+cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcmp_port =
+	TOKEN_STRING_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			port, "port");
+cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcmp_meter =
+	TOKEN_STRING_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			meter, "meter");
+cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcmp_profile =
+	TOKEN_STRING_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			profile, "profile");
+cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcmp_srtcmp =
+	TOKEN_STRING_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			srtcmp, "srtcmp");
+cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcmp_port_id =
+	TOKEN_NUM_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			port_id, RTE_UINT16);
+cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcmp_profile_id =
+	TOKEN_NUM_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			profile_id, RTE_UINT32);
+cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcmp_cir =
+	TOKEN_NUM_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			cir, RTE_UINT64);
+cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcmp_cbs =
+	TOKEN_NUM_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			cbs, RTE_UINT64);
+cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcmp_ebs =
+	TOKEN_NUM_INITIALIZER(
+		struct cmd_add_port_meter_profile_srtcmp_result,
+			ebs, RTE_UINT64);
+
+static void cmd_add_port_meter_profile_srtcmp_parsed(void *parsed_result,
+	__rte_unused struct cmdline *cl,
+	__rte_unused void *data)
+{
+	struct cmd_add_port_meter_profile_srtcmp_result *res = parsed_result;
+	struct rte_mtr_meter_profile mp;
+	struct rte_mtr_error error;
+	uint32_t profile_id = res->profile_id;
+	uint16_t port_id = res->port_id;
+	int ret;
+
+	if (port_id_is_invalid(port_id, ENABLED_WARN))
+		return;
+
+	/* Private shaper profile params */
+	memset(&mp, 0, sizeof(struct rte_mtr_meter_profile));
+	mp.alg = RTE_MTR_SRTCMP;
+	mp.srtcmp.cir = res->cir;
+	mp.srtcmp.cbs = res->cbs;
+	mp.srtcmp.ebs = res->ebs;
+
+	ret = rte_mtr_meter_profile_add(port_id, profile_id, &mp, &error);
+	if (ret != 0) {
+		print_err_msg(&error);
+		return;
+	}
+}
+
+cmdline_parse_inst_t cmd_add_port_meter_profile_srtcmp = {
+	.f = cmd_add_port_meter_profile_srtcmp_parsed,
+	.data = NULL,
+	.help_str = "Add port meter profile srtcmp",
+	.tokens = {
+		(void *)&cmd_add_port_meter_profile_srtcmp_add,
+		(void *)&cmd_add_port_meter_profile_srtcmp_port,
+		(void *)&cmd_add_port_meter_profile_srtcmp_meter,
+		(void *)&cmd_add_port_meter_profile_srtcmp_profile,
+		(void *)&cmd_add_port_meter_profile_srtcmp_srtcmp,
+		(void *)&cmd_add_port_meter_profile_srtcmp_port_id,
+		(void *)&cmd_add_port_meter_profile_srtcmp_profile_id,
+		(void *)&cmd_add_port_meter_profile_srtcmp_cir,
+		(void *)&cmd_add_port_meter_profile_srtcmp_cbs,
+		(void *)&cmd_add_port_meter_profile_srtcmp_ebs,
+		NULL,
+	},
+};
+
 /* *** Delete Port Meter Profile *** */
 struct cmd_del_port_meter_profile_result {
 	cmdline_fixed_string_t del;
diff --git a/app/test-pmd/cmdline_mtr.h b/app/test-pmd/cmdline_mtr.h
index e69d6da023..01ef85e1e7 100644
--- a/app/test-pmd/cmdline_mtr.h
+++ b/app/test-pmd/cmdline_mtr.h
@@ -10,6 +10,7 @@ extern cmdline_parse_inst_t cmd_show_port_meter_cap;
 extern cmdline_parse_inst_t cmd_add_port_meter_profile_srtcm;
 extern cmdline_parse_inst_t cmd_add_port_meter_profile_trtcm;
 extern cmdline_parse_inst_t cmd_add_port_meter_profile_trtcm_rfc4115;
+extern cmdline_parse_inst_t cmd_add_port_meter_profile_srtcmp;
 extern cmdline_parse_inst_t cmd_del_port_meter_profile;
 extern cmdline_parse_inst_t cmd_create_port_meter;
 extern cmdline_parse_inst_t cmd_enable_port_meter;
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 37278d31d6..d11de05583 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -2734,6 +2734,21 @@ where:
 * ``cbs``: Committed burst size (bytes).
 * ``ebs``: Excess burst size (bytes).
 
+add port meter profile (srTcmp)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Add meter profile (srTcmp) to the ethernet device::
+
+   testpmd> add port meter profile srtcmp (port_id) (profile_id) \
+   (cir) (cbs) (ebs)
+
+where:
+
+* ``profile_id``: ID for the meter profile.
+* ``cpr``: Committed Information Rate (CIR) (packets/second).
+* ``cbs``: Committed Burst Size (CBS) (packets).
+* ``ebs``: Excess Burst Size (EBS) (packets).
+
 delete port meter profile
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
-- 
2.21.0

Re: [dpdk-dev] [RFC v4 4/4] app/testpmd: add meter pps mode cmd

[Li, Xiaoyun]

Hi

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Li Zhang
> Sent: Monday, March 1, 2021 18:36
> To: dekelp@nvidia.com; orika@nvidia.com; viacheslavo@nvidia.com;
> matan@nvidia.com
> Cc: dev@dpdk.org; thomas@monjalon.net; rasland@nvidia.com;
> mb@smartsharesystems.com; ajit.khaparde@broadcom.com
> Subject: [dpdk-dev] [RFC v4 4/4] app/testpmd: add meter pps mode cmd
> 
> Support meter pps mode
> 
> Signed-off-by: Li Zhang <lizh@nvidia.com>
> ---
>  app/test-pmd/cmdline.c                      |   4 +
>  app/test-pmd/cmdline_mtr.c                  | 105 ++++++++++++++++++++
>  app/test-pmd/cmdline_mtr.h                  |   1 +
>  doc/guides/testpmd_app_ug/testpmd_funcs.rst |  15 +++
>  4 files changed, 125 insertions(+)
> 
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> d274a7cb8c..1a3fc644dc 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -698,6 +698,9 @@ static void cmd_help_long_parsed(void *parsed_result,
>  			"add port meter profile trtcm_rfc4115 (port_id)
> (profile_id) (cir) (eir) (cbs) (ebs)\n"
>  			"    meter profile add - trtcm rfc 4115\n\n"
> 
> +			"add port meter profile srtcmp (port_id) (profile_id)
> (cipr) (cpbs) (epbs)\n"
> +			"    meter profile add - srtcmp packet per second\n\n"
> +
>  			"del port meter profile (port_id) (profile_id)\n"
>  			"    meter profile delete\n\n"
> 
> @@ -17006,6 +17009,7 @@ cmdline_parse_ctx_t main_ctx[] = {
>  	(cmdline_parse_inst_t *)&cmd_show_port_meter_cap,
>  	(cmdline_parse_inst_t *)&cmd_add_port_meter_profile_srtcm,
>  	(cmdline_parse_inst_t *)&cmd_add_port_meter_profile_trtcm,
> +	(cmdline_parse_inst_t *)&cmd_add_port_meter_profile_srtcmp,
>  	(cmdline_parse_inst_t *)&cmd_del_port_meter_profile,
>  	(cmdline_parse_inst_t *)&cmd_create_port_meter,
>  	(cmdline_parse_inst_t *)&cmd_enable_port_meter, diff --git
> a/app/test-pmd/cmdline_mtr.c b/app/test-pmd/cmdline_mtr.c index
> 399ee56e07..3f62240a0d 100644
> --- a/app/test-pmd/cmdline_mtr.c
> +++ b/app/test-pmd/cmdline_mtr.c
> @@ -295,6 +295,8 @@ static void cmd_show_port_meter_cap_parsed(void
> *parsed_result,
>  		cap.meter_trtcm_rfc2698_n_max);
>  	printf("cap.meter_trtcm_rfc4115_n_max %" PRIu32 "\n",
>  		cap.meter_trtcm_rfc4115_n_max);
> +	printf("cap.meter_srtcmp_n_max %" PRIu32 "\n",
> +		cap.meter_srtcmp_n_max);
>  	printf("cap.meter_rate_max %" PRIu64 "\n", cap.meter_rate_max);
>  	printf("cap.color_aware_srtcm_rfc2697_supported %" PRId32 "\n",
>  		cap.color_aware_srtcm_rfc2697_supported);
> @@ -302,6 +304,8 @@ static void cmd_show_port_meter_cap_parsed(void
> *parsed_result,
>  		cap.color_aware_trtcm_rfc2698_supported);
>  	printf("cap.color_aware_trtcm_rfc4115_supported %" PRId32 "\n",
>  		cap.color_aware_trtcm_rfc4115_supported);
> +	printf("cap.color_aware_srtcmp_supported %" PRId32 "\n",
> +		cap.color_aware_srtcmp_supported);
>  	printf("cap.policer_action_recolor_supported %" PRId32 "\n",
>  		cap.policer_action_recolor_supported);
>  	printf("cap.policer_action_drop_supported %" PRId32 "\n", @@ -644,6
> +648,107 @@ cmdline_parse_inst_t
> cmd_add_port_meter_profile_trtcm_rfc4115 = {
>  	},
>  };
> 
> +/* *** Add Port Meter Profile srtcmp *** */ struct
> +cmd_add_port_meter_profile_srtcmp_result {
> +	cmdline_fixed_string_t add;
> +	cmdline_fixed_string_t port;
> +	cmdline_fixed_string_t meter;
> +	cmdline_fixed_string_t profile;
> +	cmdline_fixed_string_t srtcmp;
> +	uint16_t port_id;
> +	uint32_t profile_id;
> +	uint64_t cir;
> +	uint64_t cbs;
> +	uint64_t ebs;
> +};
> +
> +cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcmp_add =
> +	TOKEN_STRING_INITIALIZER(
> +		struct cmd_add_port_meter_profile_srtcmp_result, add, "add");
> +cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcmp_port =
> +	TOKEN_STRING_INITIALIZER(
> +		struct cmd_add_port_meter_profile_srtcmp_result,
> +			port, "port");
> +cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcmp_meter =
> +	TOKEN_STRING_INITIALIZER(
> +		struct cmd_add_port_meter_profile_srtcmp_result,
> +			meter, "meter");
> +cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcmp_profile =
> +	TOKEN_STRING_INITIALIZER(
> +		struct cmd_add_port_meter_profile_srtcmp_result,
> +			profile, "profile");
> +cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcmp_srtcmp =
> +	TOKEN_STRING_INITIALIZER(
> +		struct cmd_add_port_meter_profile_srtcmp_result,
> +			srtcmp, "srtcmp");
> +cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcmp_port_id =
> +	TOKEN_NUM_INITIALIZER(
> +		struct cmd_add_port_meter_profile_srtcmp_result,
> +			port_id, RTE_UINT16);
> +cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcmp_profile_id
> =
> +	TOKEN_NUM_INITIALIZER(
> +		struct cmd_add_port_meter_profile_srtcmp_result,
> +			profile_id, RTE_UINT32);
> +cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcmp_cir =
> +	TOKEN_NUM_INITIALIZER(
> +		struct cmd_add_port_meter_profile_srtcmp_result,
> +			cir, RTE_UINT64);
> +cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcmp_cbs =
> +	TOKEN_NUM_INITIALIZER(
> +		struct cmd_add_port_meter_profile_srtcmp_result,
> +			cbs, RTE_UINT64);
> +cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcmp_ebs =
> +	TOKEN_NUM_INITIALIZER(
> +		struct cmd_add_port_meter_profile_srtcmp_result,
> +			ebs, RTE_UINT64);
> +
> +static void cmd_add_port_meter_profile_srtcmp_parsed(void *parsed_result,
> +	__rte_unused struct cmdline *cl,
> +	__rte_unused void *data)
> +{
> +	struct cmd_add_port_meter_profile_srtcmp_result *res = parsed_result;
> +	struct rte_mtr_meter_profile mp;
> +	struct rte_mtr_error error;
> +	uint32_t profile_id = res->profile_id;
> +	uint16_t port_id = res->port_id;
> +	int ret;
> +
> +	if (port_id_is_invalid(port_id, ENABLED_WARN))
> +		return;
> +
> +	/* Private shaper profile params */
> +	memset(&mp, 0, sizeof(struct rte_mtr_meter_profile));
> +	mp.alg = RTE_MTR_SRTCMP;
> +	mp.srtcmp.cir = res->cir;
> +	mp.srtcmp.cbs = res->cbs;
> +	mp.srtcmp.ebs = res->ebs;
> +
> +	ret = rte_mtr_meter_profile_add(port_id, profile_id, &mp, &error);
> +	if (ret != 0) {
> +		print_err_msg(&error);
> +		return;
> +	}
> +}
> +
> +cmdline_parse_inst_t cmd_add_port_meter_profile_srtcmp = {
> +	.f = cmd_add_port_meter_profile_srtcmp_parsed,
> +	.data = NULL,
> +	.help_str = "Add port meter profile srtcmp",

helper_str is the hint that users can follow to tap the command. Please follow other commands behavior.
You can refer to the recent commit 618f0f4ac689f9255eecbef9202e77e35a9a7ceb which fixes all wrong helper_str in meter commands.

> +	.tokens = {
> +		(void *)&cmd_add_port_meter_profile_srtcmp_add,
> +		(void *)&cmd_add_port_meter_profile_srtcmp_port,
> +		(void *)&cmd_add_port_meter_profile_srtcmp_meter,
> +		(void *)&cmd_add_port_meter_profile_srtcmp_profile,
> +		(void *)&cmd_add_port_meter_profile_srtcmp_srtcmp,
> +		(void *)&cmd_add_port_meter_profile_srtcmp_port_id,
> +		(void *)&cmd_add_port_meter_profile_srtcmp_profile_id,
> +		(void *)&cmd_add_port_meter_profile_srtcmp_cir,
> +		(void *)&cmd_add_port_meter_profile_srtcmp_cbs,
> +		(void *)&cmd_add_port_meter_profile_srtcmp_ebs,
> +		NULL,
> +	},
> +};
> +
>  /* *** Delete Port Meter Profile *** */  struct
> cmd_del_port_meter_profile_result {
>  	cmdline_fixed_string_t del;
> diff --git a/app/test-pmd/cmdline_mtr.h b/app/test-pmd/cmdline_mtr.h index
> e69d6da023..01ef85e1e7 100644
> --- a/app/test-pmd/cmdline_mtr.h
> +++ b/app/test-pmd/cmdline_mtr.h
> @@ -10,6 +10,7 @@ extern cmdline_parse_inst_t cmd_show_port_meter_cap;
> extern cmdline_parse_inst_t cmd_add_port_meter_profile_srtcm;  extern
> cmdline_parse_inst_t cmd_add_port_meter_profile_trtcm;  extern
> cmdline_parse_inst_t cmd_add_port_meter_profile_trtcm_rfc4115;
> +extern cmdline_parse_inst_t cmd_add_port_meter_profile_srtcmp;
>  extern cmdline_parse_inst_t cmd_del_port_meter_profile;  extern
> cmdline_parse_inst_t cmd_create_port_meter;  extern cmdline_parse_inst_t
> cmd_enable_port_meter; diff --git
> a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> index 37278d31d6..d11de05583 100644
> --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> @@ -2734,6 +2734,21 @@ where:
>  * ``cbs``: Committed burst size (bytes).
>  * ``ebs``: Excess burst size (bytes).
> 
> +add port meter profile (srTcmp)
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +Add meter profile (srTcmp) to the ethernet device::
> +
> +   testpmd> add port meter profile srtcmp (port_id) (profile_id) \
> +   (cir) (cbs) (ebs)
> +
> +where:
> +
> +* ``profile_id``: ID for the meter profile.
> +* ``cpr``: Committed Information Rate (CIR) (packets/second).
> +* ``cbs``: Committed Burst Size (CBS) (packets).
> +* ``ebs``: Excess Burst Size (EBS) (packets).
> +
>  delete port meter profile
>  ~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> --
> 2.21.0

Re: [dpdk-dev] [RFC v4 4/4] app/testpmd: add meter pps mode cmd

[Li Zhang]

Hi Xiao yun,

Thanks for your comments.
We will follow other commands in our new command's helper_str.

Regards,
Li Zhang
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Li, Xiaoyun
> Sent: Tuesday, March 2, 2021 9:48 AM
> To: Li Zhang <lizh@nvidia.com>; Dekel Peled <dekelp@nvidia.com>; Ori Kam
> <orika@nvidia.com>; Slava Ovsiienko <viacheslavo@nvidia.com>; Matan
> Azrad <matan@nvidia.com>
> Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon <thomas@monjalon.net>;
> Raslan Darawsheh <rasland@nvidia.com>; mb@smartsharesystems.com;
> ajit.khaparde@broadcom.com
> Subject: Re: [dpdk-dev] [RFC v4 4/4] app/testpmd: add meter pps mode cmd
> 
> Hi
> 
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Li Zhang
> > Sent: Monday, March 1, 2021 18:36
> > To: dekelp@nvidia.com; orika@nvidia.com; viacheslavo@nvidia.com;
> > matan@nvidia.com
> > Cc: dev@dpdk.org; thomas@monjalon.net; rasland@nvidia.com;
> > mb@smartsharesystems.com; ajit.khaparde@broadcom.com
> > Subject: [dpdk-dev] [RFC v4 4/4] app/testpmd: add meter pps mode cmd
> >
> > Support meter pps mode
> >
> > Signed-off-by: Li Zhang <lizh@nvidia.com>
> > ---
> >  app/test-pmd/cmdline.c                      |   4 +
> >  app/test-pmd/cmdline_mtr.c                  | 105 ++++++++++++++++++++
> >  app/test-pmd/cmdline_mtr.h                  |   1 +
> >  doc/guides/testpmd_app_ug/testpmd_funcs.rst |  15 +++
> >  4 files changed, 125 insertions(+)
> >
> > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> > d274a7cb8c..1a3fc644dc 100644
> > --- a/app/test-pmd/cmdline.c
> > +++ b/app/test-pmd/cmdline.c
> > @@ -698,6 +698,9 @@ static void cmd_help_long_parsed(void
> *parsed_result,
> >  			"add port meter profile trtcm_rfc4115 (port_id)
> > (profile_id) (cir) (eir) (cbs) (ebs)\n"
> >  			"    meter profile add - trtcm rfc 4115\n\n"
> >
> > +			"add port meter profile srtcmp (port_id) (profile_id)
> > (cipr) (cpbs) (epbs)\n"
> > +			"    meter profile add - srtcmp packet per second\n\n"
> > +
> >  			"del port meter profile (port_id) (profile_id)\n"
> >  			"    meter profile delete\n\n"
> >
> > @@ -17006,6 +17009,7 @@ cmdline_parse_ctx_t main_ctx[] = {
> >  	(cmdline_parse_inst_t *)&cmd_show_port_meter_cap,
> >  	(cmdline_parse_inst_t *)&cmd_add_port_meter_profile_srtcm,
> >  	(cmdline_parse_inst_t *)&cmd_add_port_meter_profile_trtcm,
> > +	(cmdline_parse_inst_t *)&cmd_add_port_meter_profile_srtcmp,
> >  	(cmdline_parse_inst_t *)&cmd_del_port_meter_profile,
> >  	(cmdline_parse_inst_t *)&cmd_create_port_meter,
> >  	(cmdline_parse_inst_t *)&cmd_enable_port_meter, diff --git
> > a/app/test-pmd/cmdline_mtr.c b/app/test-pmd/cmdline_mtr.c index
> > 399ee56e07..3f62240a0d 100644
> > --- a/app/test-pmd/cmdline_mtr.c
> > +++ b/app/test-pmd/cmdline_mtr.c
> > @@ -295,6 +295,8 @@ static void cmd_show_port_meter_cap_parsed(void
> > *parsed_result,
> >  		cap.meter_trtcm_rfc2698_n_max);
> >  	printf("cap.meter_trtcm_rfc4115_n_max %" PRIu32 "\n",
> >  		cap.meter_trtcm_rfc4115_n_max);
> > +	printf("cap.meter_srtcmp_n_max %" PRIu32 "\n",
> > +		cap.meter_srtcmp_n_max);
> >  	printf("cap.meter_rate_max %" PRIu64 "\n", cap.meter_rate_max);
> >  	printf("cap.color_aware_srtcm_rfc2697_supported %" PRId32 "\n",
> >  		cap.color_aware_srtcm_rfc2697_supported);
> > @@ -302,6 +304,8 @@ static void cmd_show_port_meter_cap_parsed(void
> > *parsed_result,
> >  		cap.color_aware_trtcm_rfc2698_supported);
> >  	printf("cap.color_aware_trtcm_rfc4115_supported %" PRId32 "\n",
> >  		cap.color_aware_trtcm_rfc4115_supported);
> > +	printf("cap.color_aware_srtcmp_supported %" PRId32 "\n",
> > +		cap.color_aware_srtcmp_supported);
> >  	printf("cap.policer_action_recolor_supported %" PRId32 "\n",
> >  		cap.policer_action_recolor_supported);
> >  	printf("cap.policer_action_drop_supported %" PRId32 "\n", @@ -
> 644,6
> > +648,107 @@ cmdline_parse_inst_t
> > cmd_add_port_meter_profile_trtcm_rfc4115 = {
> >  	},
> >  };
> >
> > +/* *** Add Port Meter Profile srtcmp *** */ struct
> > +cmd_add_port_meter_profile_srtcmp_result {
> > +	cmdline_fixed_string_t add;
> > +	cmdline_fixed_string_t port;
> > +	cmdline_fixed_string_t meter;
> > +	cmdline_fixed_string_t profile;
> > +	cmdline_fixed_string_t srtcmp;
> > +	uint16_t port_id;
> > +	uint32_t profile_id;
> > +	uint64_t cir;
> > +	uint64_t cbs;
> > +	uint64_t ebs;
> > +};
> > +
> > +cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcmp_add
> =
> > +	TOKEN_STRING_INITIALIZER(
> > +		struct cmd_add_port_meter_profile_srtcmp_result, add,
> "add");
> > +cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcmp_port
> =
> > +	TOKEN_STRING_INITIALIZER(
> > +		struct cmd_add_port_meter_profile_srtcmp_result,
> > +			port, "port");
> > +cmdline_parse_token_string_t
> cmd_add_port_meter_profile_srtcmp_meter =
> > +	TOKEN_STRING_INITIALIZER(
> > +		struct cmd_add_port_meter_profile_srtcmp_result,
> > +			meter, "meter");
> > +cmdline_parse_token_string_t
> cmd_add_port_meter_profile_srtcmp_profile =
> > +	TOKEN_STRING_INITIALIZER(
> > +		struct cmd_add_port_meter_profile_srtcmp_result,
> > +			profile, "profile");
> > +cmdline_parse_token_string_t
> cmd_add_port_meter_profile_srtcmp_srtcmp =
> > +	TOKEN_STRING_INITIALIZER(
> > +		struct cmd_add_port_meter_profile_srtcmp_result,
> > +			srtcmp, "srtcmp");
> > +cmdline_parse_token_num_t
> cmd_add_port_meter_profile_srtcmp_port_id =
> > +	TOKEN_NUM_INITIALIZER(
> > +		struct cmd_add_port_meter_profile_srtcmp_result,
> > +			port_id, RTE_UINT16);
> > +cmdline_parse_token_num_t
> > +cmd_add_port_meter_profile_srtcmp_profile_id
> > =
> > +	TOKEN_NUM_INITIALIZER(
> > +		struct cmd_add_port_meter_profile_srtcmp_result,
> > +			profile_id, RTE_UINT32);
> > +cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcmp_cir =
> > +	TOKEN_NUM_INITIALIZER(
> > +		struct cmd_add_port_meter_profile_srtcmp_result,
> > +			cir, RTE_UINT64);
> > +cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcmp_cbs =
> > +	TOKEN_NUM_INITIALIZER(
> > +		struct cmd_add_port_meter_profile_srtcmp_result,
> > +			cbs, RTE_UINT64);
> > +cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcmp_ebs =
> > +	TOKEN_NUM_INITIALIZER(
> > +		struct cmd_add_port_meter_profile_srtcmp_result,
> > +			ebs, RTE_UINT64);
> > +
> > +static void cmd_add_port_meter_profile_srtcmp_parsed(void
> *parsed_result,
> > +	__rte_unused struct cmdline *cl,
> > +	__rte_unused void *data)
> > +{
> > +	struct cmd_add_port_meter_profile_srtcmp_result *res =
> parsed_result;
> > +	struct rte_mtr_meter_profile mp;
> > +	struct rte_mtr_error error;
> > +	uint32_t profile_id = res->profile_id;
> > +	uint16_t port_id = res->port_id;
> > +	int ret;
> > +
> > +	if (port_id_is_invalid(port_id, ENABLED_WARN))
> > +		return;
> > +
> > +	/* Private shaper profile params */
> > +	memset(&mp, 0, sizeof(struct rte_mtr_meter_profile));
> > +	mp.alg = RTE_MTR_SRTCMP;
> > +	mp.srtcmp.cir = res->cir;
> > +	mp.srtcmp.cbs = res->cbs;
> > +	mp.srtcmp.ebs = res->ebs;
> > +
> > +	ret = rte_mtr_meter_profile_add(port_id, profile_id, &mp, &error);
> > +	if (ret != 0) {
> > +		print_err_msg(&error);
> > +		return;
> > +	}
> > +}
> > +
> > +cmdline_parse_inst_t cmd_add_port_meter_profile_srtcmp = {
> > +	.f = cmd_add_port_meter_profile_srtcmp_parsed,
> > +	.data = NULL,
> > +	.help_str = "Add port meter profile srtcmp",
> 
> helper_str is the hint that users can follow to tap the command. Please follow
> other commands behavior.
> You can refer to the recent commit
> 618f0f4ac689f9255eecbef9202e77e35a9a7ceb which fixes all wrong helper_str
> in meter commands.
> 
> > +	.tokens = {
> > +		(void *)&cmd_add_port_meter_profile_srtcmp_add,
> > +		(void *)&cmd_add_port_meter_profile_srtcmp_port,
> > +		(void *)&cmd_add_port_meter_profile_srtcmp_meter,
> > +		(void *)&cmd_add_port_meter_profile_srtcmp_profile,
> > +		(void *)&cmd_add_port_meter_profile_srtcmp_srtcmp,
> > +		(void *)&cmd_add_port_meter_profile_srtcmp_port_id,
> > +		(void *)&cmd_add_port_meter_profile_srtcmp_profile_id,
> > +		(void *)&cmd_add_port_meter_profile_srtcmp_cir,
> > +		(void *)&cmd_add_port_meter_profile_srtcmp_cbs,
> > +		(void *)&cmd_add_port_meter_profile_srtcmp_ebs,
> > +		NULL,
> > +	},
> > +};
> > +
> >  /* *** Delete Port Meter Profile *** */  struct
> > cmd_del_port_meter_profile_result {
> >  	cmdline_fixed_string_t del;
> > diff --git a/app/test-pmd/cmdline_mtr.h b/app/test-pmd/cmdline_mtr.h
> > index
> > e69d6da023..01ef85e1e7 100644
> > --- a/app/test-pmd/cmdline_mtr.h
> > +++ b/app/test-pmd/cmdline_mtr.h
> > @@ -10,6 +10,7 @@ extern cmdline_parse_inst_t
> cmd_show_port_meter_cap;
> > extern cmdline_parse_inst_t cmd_add_port_meter_profile_srtcm;  extern
> > cmdline_parse_inst_t cmd_add_port_meter_profile_trtcm;  extern
> > cmdline_parse_inst_t cmd_add_port_meter_profile_trtcm_rfc4115;
> > +extern cmdline_parse_inst_t cmd_add_port_meter_profile_srtcmp;
> >  extern cmdline_parse_inst_t cmd_del_port_meter_profile;  extern
> > cmdline_parse_inst_t cmd_create_port_meter;  extern
> > cmdline_parse_inst_t cmd_enable_port_meter; diff --git
> > a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > index 37278d31d6..d11de05583 100644
> > --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > @@ -2734,6 +2734,21 @@ where:
> >  * ``cbs``: Committed burst size (bytes).
> >  * ``ebs``: Excess burst size (bytes).
> >
> > +add port meter profile (srTcmp)
> > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > +
> > +Add meter profile (srTcmp) to the ethernet device::
> > +
> > +   testpmd> add port meter profile srtcmp (port_id) (profile_id) \
> > +   (cir) (cbs) (ebs)
> > +
> > +where:
> > +
> > +* ``profile_id``: ID for the meter profile.
> > +* ``cpr``: Committed Information Rate (CIR) (packets/second).
> > +* ``cbs``: Committed Burst Size (CBS) (packets).
> > +* ``ebs``: Excess Burst Size (EBS) (packets).
> > +
> >  delete port meter profile
> >  ~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > --
> > 2.21.0