From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas@monjalon.net> Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 972C72C18 for <dev@dpdk.org>; Fri, 4 Aug 2017 17:16:30 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 0F92F20B2D; Fri, 4 Aug 2017 11:16:30 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 04 Aug 2017 11:16:30 -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=hP3lNI3z5p+Otjj o8Mblge2RcsZD6SBzpujjsVaMzLU=; b=f/STSDVm3/C4m0KpRfJ7dNYT+fQJo0/ zHCccEgFBt2H3TneWaEJmtkcuvgBrBqU/y78BSRJMT3HybyHS1TwDK2b8i9CbS3x V4PGT1+td4u9w9XKlU9F4V9HLd4ZoShhY0Wd+hbh7NIaHl+gF/FZUUnt8u91ra2r 0Q6SsiLZ02sg= 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=hP3lNI3z5p+Otjjo8Mblge2RcsZD6SBzpujjsVaMzLU=; b=adjKmd+9 iJDanMJtmioCieZyCQeKOZidwxFXMojwMyKk4FtiRiMIv9fWPBOIf1chlpFuyZk7 8NI+j6hMftON87MCRoWjxO59hVP6R8+NawPfhxyw9absW0WEVHDrElSQmgU0UgBJ JtCG2kylSojhPAghPzblyYDVdFi8ocZEJXSfO3I+Acdqal43SPdn30uEc6uERMm5 C8hNccshMdSuwCOjLeOLO6K2iaPjf3p1lZ5SELLbXDGZFH1bfxV0h4lBwKziH0Jf oQBXvY50NVC98k8GyZZsMVUm4OCSRj7so/oaPtwQA+0bOCv4B4BK6lAXkzaURQkd QFWVawqBIXhgXg== X-ME-Sender: <xms:zY-EWW2UDdMOKMIHcLZMPOTA6abVw2RkgDnuiaTS_y8t3zpudM6ixA> X-Sasl-enc: JR6wM/aFAnoB4teJvMJXrdpi5JPKP6CuOJlFcEABgORc 1501859789 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 7847824580; Fri, 4 Aug 2017 11:16:29 -0400 (EDT) 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> Date: Fri, 04 Aug 2017 17:16:28 +0200 Message-ID: <2288480.tqLemaf8ft@xps> In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891267BA8A99C@IRSMSX108.ger.corp.intel.com> References: <1501852780-191124-1-git-send-email-cristian.dumitrescu@intel.com> <2258321.CxPN5KWo1L@xps> <3EB4FA525960D640B5BDFFD6A3D891267BA8A99C@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 <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Fri, 04 Aug 2017 15:16:30 -0000 04/08/2017 17:04, Dumitrescu, Cristian: > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > 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. > > > > Never occurred to me before, but yes, I have to say it is easy to confuse these 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 = 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. > > 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 of 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 meter. This structure contains two types of data: > A) variable data: running counters per meter > B) fixed data: low level translation of configuration parameters; this should 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 shared by many objects. > > Why? For significant performance improvements, as the per object context memory footprint cuts in half or even more by moving the fixed data B) elsewhere. 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? It proves that you are an expert of this stuff and you seem to know what you do, so I trust you :) (I remove my wrong nack) > PS: Mot sure I managed to be concise, but I tried :) It was less concise but probably necessary, thanks!