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 003FB23B for ; Tue, 19 Sep 2017 18:14:18 +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; 19 Sep 2017 09:14:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,418,1500966000"; d="scan'208";a="137114716" Received: from irsmsx152.ger.corp.intel.com ([163.33.192.66]) by orsmga002.jf.intel.com with ESMTP; 19 Sep 2017 09:14:15 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.167]) by IRSMSX152.ger.corp.intel.com ([169.254.6.87]) with mapi id 14.03.0319.002; Tue, 19 Sep 2017 17:14:15 +0100 From: "Dumitrescu, Cristian" To: Hemant Agrawal , "dev@dpdk.org" CC: "thomas@monjalon.net" , "adrien.mazarguil@6wind.com" , "jerin.jacob@caviumnetworks.com" Thread-Topic: [PATCH 2/3] ethdev: add new rte_mtr API for traffic metering and policing Thread-Index: AQHTIvnMqS+xvdf9Q0eeWxqGMLJLVqKkzByggAK+fQCAFO78oA== Date: Tue, 19 Sep 2017 16:14:14 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D891267BABC059@IRSMSX108.ger.corp.intel.com> References: <1496162653-137817-3-git-send-email-cristian.dumitrescu@intel.com> <1503705973-80742-1-git-send-email-cristian.dumitrescu@intel.com> <1503705973-80742-3-git-send-email-cristian.dumitrescu@intel.com> <3EB4FA525960D640B5BDFFD6A3D891267BAB2088@IRSMSX108.ger.corp.intel.com> <5610d7e1-701b-71ea-42fc-4ac427b87eb6@nxp.com> In-Reply-To: <5610d7e1-701b-71ea-42fc-4ac427b87eb6@nxp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 2/3] ethdev: add new rte_mtr API for traffic metering and policing 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: Tue, 19 Sep 2017 16:14:19 -0000 Hi Hemant, ... > >>> +/** > >>> + * Meter profile delete > >>> + * > >>> + * Delete an existing meter profile. This operation fails when there= is > >>> + * currently at least one user (i.e. MTR object) of this profile. > >>> + * > >> > >> Do you want to do this checking at library level or at driver level? > >> Same profile can be used by two distinct drivers! > >> > >> This is applicable for other APIs as well. Your current API > >> implementation is mostly pass-through. A stateful will be better. > >> > > > > Yes, the same meter profiles can potentially be shared for a group of > ethdev ports, but unfortunately we cannot do this with the current ethdev > API, which is per port with no sharing ability between groups of ports. > > > > Here we are lucky to have just a read-only configuration template that > needs to be shared amongst ports, so the quick workaround is to define th= e > same profile for each port at the expense of some (small) work duplicatio= n. > Hopefully this is OK with you? > > > Is that mean you will create the meter profile template first and then > apply/remove that on a port? >=20 Meter profile is just the configuration params (configuration template) tha= t can be applied to many meter objects. Approach A (my proposal): Keep all API functions per port, including meter = profile create, including meter create. So in the likely case that meters o= n different ports use the same configuration, the same profile needs to be = registered once for each port. Approach B (your suggestion, if I got it right): Have a global list of prof= iles maintained internally by the library. This allows using the same profi= le on different ports, so no need to register the same profile explicitly f= or each port. The reason I don't favour approach B is it requires maintaining static glo= bal data in the library, but I don't see any tricky implications with eithe= r A or B. Do you have strong preference towards B? > how about adding a use-count to the profile? >=20 Yes, this is already part of the current proposal: the number of meter obje= cts that share the same profile (i.e. configuration template) is counted, s= o the profile can be deleted only when it does not have any users (i.e. met= er objects). > On a different lines, can we do following > 1. Metering profile is not applied to a port. Metering object maintain > the use-count. Not sure I understand your statement on: "metering object maintain the use-= count". Maybe we have a terminology misalignment on meter profile and meter= object and I am not fully getting your point? In my mind this is approach B from above. Also the above statement should b= e corrected to: metering _profile_ maintain the use-count (of how many mete= ring objects are currently using it, i.e. use the same configuration templa= te)? > 2. metering object is applied to the port, which in turn contains > metering profile. >=20 Yes, this is approach A from above :) > Regards, > Hemant Regards, Cristian