From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id D91592C18 for ; Fri, 4 Aug 2017 17:04:44 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Aug 2017 08:04:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,321,1498546800"; d="scan'208";a="119795384" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by orsmga002.jf.intel.com with ESMTP; 04 Aug 2017 08:04:42 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.133]) by IRSMSX104.ger.corp.intel.com ([169.254.5.26]) with mapi id 14.03.0319.002; Fri, 4 Aug 2017 16:04:41 +0100 From: "Dumitrescu, Cristian" To: Thomas Monjalon CC: "Horton, Remy" , "dev@dpdk.org" , "Mcnamara, John" , "Singh, Jasvinder" , "Nicolau, Radu" , "Hunt, David" Thread-Topic: [PATCH] doc: API change notice for librte_meter Thread-Index: AQHTDS4HQXpfAwzYtUSuf6fvFUIjTKJ0QnZQ///0AgCAABHJsA== Date: Fri, 4 Aug 2017 15:04:41 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D891267BA8A99C@IRSMSX108.ger.corp.intel.com> References: <1501852780-191124-1-git-send-email-cristian.dumitrescu@intel.com> <3871111.0JZd9azV8i@xps> <3EB4FA525960D640B5BDFFD6A3D891267BA8A968@IRSMSX108.ger.corp.intel.com> <2258321.CxPN5KWo1L@xps> In-Reply-To: <2258321.CxPN5KWo1L@xps> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] doc: API change notice for librte_meter X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 15:04:45 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Friday, August 4, 2017 3:49 PM > To: Dumitrescu, Cristian > Cc: Horton, Remy ; dev@dpdk.org; Mcnamara, > John ; Singh, Jasvinder > ; Nicolau, Radu ; > Hunt, David > Subject: Re: [PATCH] doc: API change notice for librte_meter >=20 > 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 paramet= er. > > > > > > 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? Th= is is > about librte_meter, nothing to do with stats/metrics. >=20 > Yes you're right! Sorry for the confusion. >=20 Never occurred to me before, but yes, I have to say it is easy to confuse t= hese two names METeR and METRics. > > This librte_meter is doing traffic metering, essentially the computing = the > packet color according to the IETF RFCs 2697 (srTCM =3D Single Rate Three= Color > Marker) and 2698 (trTCM =3D 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. >=20 > Thanks for being concise :) >=20 > > Do you need more details on the motivation? >=20 > Yes we need to understand why the configuration profiles must be > managed by the API instead of separately. The configuration profile is simply a cool name for the meter configuration= parameter set, which includes committed/peak rates, etc. The profile notion makes sense when many meter objects share the same set o= f configuration parameters, which is pretty much the de-facto behaviour. Right now, a metering object is handled through an opaque parameter, which = is really a data structure storing the low level data required to run the m= eter. This structure contains two types of data: A) variable data: running counters per meter B) fixed data: low level translation of configuration parameters; this shou= ld not be duplicated per every object, as it is shared by many objects So basically, will break the meter handle into two handles: one for the A) = data (the one we already have), and one for the B) data, which can be share= d by many objects. Why? For significant performance improvements, as the per object context me= mory footprint cuts in half or even more by moving the fixed data B) elsewh= ere. Right now, this context is 2-3 cache lines, it will eventually fit in = about half of cache line. This helps a lot when you have thousands of flows= , each with one or two meters. Makes sense? Regards, Cristian PS: Mot sure I managed to be concise, but I tried :)