From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id D762F326C for ; Fri, 4 Aug 2017 16:48:58 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 8251120D44; Fri, 4 Aug 2017 10:48:58 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 04 Aug 2017 10:48:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=i2KXhHL8omXrlKF BUV/csvhr+O6b1qRpsLtourIHU7k=; b=XnBzmgoJ7MCcjXH9MhbbUMyHYuSsKyn j6wrP2Nyl+QU8j7Mz3X1lamjAsad10aP7W9DPZ1//+/QmkMj9eVypKS446V46Z3l gRD1K76XoJMCT6mWkiGLY32QILW1yqF7NnQJaypcgHfeP7+6QKQKhLUvlzVe9PqI Tw4D+BlcDcpQ= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=i2KXhHL8omXrlKFBUV/csvhr+O6b1qRpsLtourIHU7k=; b=gO3IM531 6cEgwgrfQWi2vErYM/XX539vwcSplGR6I1I2mesp9BR+2itW350zxdU/eesVHo0o n35ekkX9co358w4zk4Jo3nY7zUcH5ciCTdz1xFRMX7aQZh/b4ELTSBmijUTT68mj fTacMD/Dbds4yKqpit5wl9zhMYQu6g/lUU9BDyIXv38rI6YLCdRJh87qB5N2g26J FOCTiEWE/EXBrllIAK/uozFVZ15cuufe767tTLdLrV68KiAl6v5BZPkxC0sbyHqw md9P1SU+Vaabn53JZbgTckK6AhJLtp2cbBb60TStgzqW5DfBrxLVLriSyiybtLoV 3xZbSRkf/ga+ZA== X-ME-Sender: X-Sasl-enc: Y9bkZ3RGGPMZP+6+rwgGg3cQijGFR9MzlMwblNQczbHe 1501858137 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id ED671246D8; Fri, 4 Aug 2017 10:48:57 -0400 (EDT) From: Thomas Monjalon To: "Dumitrescu, Cristian" Cc: "Horton, Remy" , dev@dpdk.org, "Mcnamara, John" , "Singh, Jasvinder" , "Nicolau, Radu" , "Hunt, David" Date: Fri, 04 Aug 2017 16:48:56 +0200 Message-ID: <2258321.CxPN5KWo1L@xps> In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891267BA8A968@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> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 14:48:59 -0000 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.