> -----Original Message-----
> From: Ferruh Yigit <ferruh.yi...@intel.com>
> Sent: Thursday, January 28, 2021 6:28 PM
> To: Li Zhang <l...@nvidia.com>; dek...@nvidia.com; or...@nvidia.com;
> viachesl...@nvidia.com; ma...@nvidia.com; Dumitrescu, Cristian
> <cristian.dumitre...@intel.com>
> Cc: dev@dpdk.org; tho...@monjalon.net; rasl...@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 <l...@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
