From: Thomas Monjalon <thomas@monjalon.net>
To: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>
Cc: "Horton, Remy" <remy.horton@intel.com>,
dev@dpdk.org, "Mcnamara, John" <john.mcnamara@intel.com>,
"Singh, Jasvinder" <jasvinder.singh@intel.com>,
"Nicolau, Radu" <radu.nicolau@intel.com>,
"Hunt, David" <david.hunt@intel.com>
Subject: Re: [dpdk-dev] [PATCH] doc: API change notice for librte_meter
Date: Fri, 04 Aug 2017 16:48:56 +0200 [thread overview]
Message-ID: <2258321.CxPN5KWo1L@xps> (raw)
In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891267BA8A968@IRSMSX108.ger.corp.intel.com>
04/08/2017 16:38, Dumitrescu, Cristian:
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > 04/08/2017 15:19, Cristian Dumitrescu:
> > > +* librte_meter: The API will change to accommodate configuration
> > profiles.
> > > + Most of the API functions will have an additional opaque parameter.
> >
> > Why?
> > Why opaque parameter?
> > If you want to use it with a configuration file, you just have to
> > implement a configuration file in your application.
> >
> > Moreover, I already explained my fear of adding this library in DPDK
> > which is really an application-level statistics lib.
> >
> > Without more explanations, my vote is a nack.
> >
> > However I remember there was a promise to merge every metrics libs in
> > one.
>
> Thomas,
>
> Confusion with librte_metrics, which is a totally different library? This is about librte_meter, nothing to do with stats/metrics.
Yes you're right! Sorry for the confusion.
> This librte_meter is doing traffic metering, essentially the computing the packet color according to the IETF RFCs 2697 (srTCM = Single Rate Three Color Marker) and 2698 (trTCM = Two Rate Three Color Marker). This is a fundamental block for pretty much every edge router upstream path.
>
> You asked me on numerous occasions to be concise, so here is a concise deprecation notice. I have to say initially I wrote a more laborious one, then I remembered your advice and cut it down to this version.
Thanks for being concise :)
> Do you need more details on the motivation?
Yes we need to understand why the configuration profiles must be
managed by the API instead of separately.
next prev parent reply other threads:[~2017-08-04 14:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-04 13:19 Cristian Dumitrescu
2017-08-04 14:28 ` Thomas Monjalon
2017-08-04 14:38 ` Dumitrescu, Cristian
2017-08-04 14:48 ` Thomas Monjalon [this message]
2017-08-04 15:04 ` Dumitrescu, Cristian
2017-08-04 15:16 ` Thomas Monjalon
2017-08-08 10:30 ` Thomas Monjalon
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=2258321.CxPN5KWo1L@xps \
--to=thomas@monjalon.net \
--cc=cristian.dumitrescu@intel.com \
--cc=david.hunt@intel.com \
--cc=dev@dpdk.org \
--cc=jasvinder.singh@intel.com \
--cc=john.mcnamara@intel.com \
--cc=radu.nicolau@intel.com \
--cc=remy.horton@intel.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).