From: Matan Azrad <matan@nvidia.com>
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" <dev@dpdk.org>,
NBU-Contact-Thomas Monjalon <thomas@monjalon.net>,
Raslan Darawsheh <rasland@nvidia.com>,
"mb@smartsharesystems.com" <mb@smartsharesystems.com>,
"ajit.khaparde@broadcom.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
Date: Tue, 2 Mar 2021 12:37:04 +0000 [thread overview]
Message-ID: <MW2PR12MB2492BF8498CC242073CB3BBDDF999@MW2PR12MB2492.namprd12.prod.outlook.com> (raw)
In-Reply-To: <MWHPR11MB2032625400B7A15D4082BF9BEB999@MWHPR11MB2032.namprd11.prod.outlook.com>
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
next prev parent reply other threads:[~2021-03-02 12:37 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-25 1:02 [dpdk-dev] [RFC 0/1] lib/librte_ethdev: Meter algorithms support packet per second Li Zhang
2021-01-25 1:02 ` [dpdk-dev] [PATCH] [RFC]: adds support PPS(packet per second) on meter Li Zhang
2021-01-25 1:20 ` [dpdk-dev] [RFC 0/1] lib/librte_ethdev: Meter algorithms support packet per second Li Zhang
2021-01-25 1:20 ` [dpdk-dev] [PATCH] [RFC, v2]: adds support PPS(packet per second) on meter Li Zhang
2021-01-28 18:27 ` Ferruh Yigit
2021-02-12 7:40 ` Morten Brørup
2021-02-23 2:07 ` Li Zhang
2021-02-23 8:24 ` Morten Brørup
2021-03-01 3:16 ` Li Zhang
2021-03-01 3:31 ` Ajit Khaparde
2021-03-01 7:20 ` Morten Brørup
2021-03-01 13:08 ` Dumitrescu, Cristian
2021-03-01 9:39 ` [dpdk-dev] [RFC v3 0/4] " Li Zhang
2021-03-01 9:39 ` [dpdk-dev] [RFC v3 1/4] ethdev: add meter PPS profile Li Zhang
2021-03-01 9:39 ` [dpdk-dev] [RFC v3 2/4] common/mlx5: add meter mode definition in PRM file Li Zhang
2021-03-01 9:39 ` [dpdk-dev] [RFC v3 3/4] net/mlx5: support meter PPS profile Li Zhang
2021-03-01 9:40 ` [dpdk-dev] [RFC v3 4/4] app/testpmd: add meter pps mode cmd Li Zhang
2021-03-01 9:43 ` [dpdk-dev] [RFC v3 0/4] adds support PPS(packet per second) on meter Li Zhang
2021-03-01 9:43 ` [dpdk-dev] [RFC v3 1/4] ethdev: add meter PPS profile Li Zhang
2021-03-01 9:43 ` [dpdk-dev] [RFC v3 2/4] common/mlx5: add meter mode definition in PRM file Li Zhang
2021-03-01 9:43 ` [dpdk-dev] [RFC v3 3/4] net/mlx5: support meter PPS profile Li Zhang
2021-03-01 9:43 ` [dpdk-dev] [RFC v3 4/4] app/testpmd: add meter pps mode cmd Li Zhang
2021-03-01 9:53 ` [dpdk-dev] [RFC v3 0/4] adds support PPS(packet per second) on meter Li Zhang
2021-03-01 9:53 ` [dpdk-dev] [RFC v3 1/4] ethdev: add meter PPS profile Li Zhang
2021-03-01 9:53 ` [dpdk-dev] [RFC v3 2/4] common/mlx5: add meter mode definition in PRM file Li Zhang
2021-03-01 9:53 ` [dpdk-dev] [RFC v3 3/4] net/mlx5: support meter PPS profile Li Zhang
2021-03-01 9:53 ` [dpdk-dev] [RFC v3 4/4] app/testpmd: add meter pps mode cmd Li Zhang
2021-02-12 21:35 ` [dpdk-dev] [PATCH] [RFC]: adds support PPS(packet per second) on meter Ajit Khaparde
2021-02-23 2:11 ` Li Zhang
2021-03-01 10:35 ` [dpdk-dev] [RFC v4 0/4] " Li Zhang
2021-03-01 10:35 ` [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile Li Zhang
2021-03-01 13:20 ` Dumitrescu, Cristian
2021-03-01 15:53 ` Thomas Monjalon
2021-03-02 1:27 ` Li Zhang
2021-03-02 1:46 ` Ajit Khaparde
2021-03-02 12:13 ` Dumitrescu, Cristian
2021-03-02 7:02 ` Matan Azrad
2021-03-02 12:29 ` Dumitrescu, Cristian
2021-03-02 12:37 ` Matan Azrad [this message]
2021-03-02 14:33 ` Dumitrescu, Cristian
2021-03-02 18:10 ` Matan Azrad
2021-03-03 20:35 ` Dumitrescu, Cristian
2021-03-04 6:34 ` Matan Azrad
2021-03-05 18:44 ` Dumitrescu, Cristian
2021-03-01 10:35 ` [dpdk-dev] [RFC v4 2/4] common/mlx5: add meter mode definition in PRM file Li Zhang
2021-03-01 10:35 ` [dpdk-dev] [RFC v4 3/4] net/mlx5: support meter PPS profile Li Zhang
2021-03-01 10:35 ` [dpdk-dev] [RFC v4 4/4] app/testpmd: add meter pps mode cmd Li Zhang
2021-03-02 1:48 ` Li, Xiaoyun
2021-03-02 3:04 ` Li Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=MW2PR12MB2492BF8498CC242073CB3BBDDF999@MW2PR12MB2492.namprd12.prod.outlook.com \
--to=matan@nvidia.com \
--cc=ajit.khaparde@broadcom.com \
--cc=cristian.dumitrescu@intel.com \
--cc=dekelp@nvidia.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=jasvinder.singh@intel.com \
--cc=lizh@nvidia.com \
--cc=mb@smartsharesystems.com \
--cc=orika@nvidia.com \
--cc=rasland@nvidia.com \
--cc=thomas@monjalon.net \
--cc=viacheslavo@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).