From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 9948E1B1B9 for ; Fri, 6 Oct 2017 16:50:38 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Oct 2017 07:50:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,483,1500966000"; d="scan'208";a="143567546" Received: from irsmsx151.ger.corp.intel.com ([163.33.192.59]) by orsmga002.jf.intel.com with ESMTP; 06 Oct 2017 07:50:36 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.167]) by IRSMSX151.ger.corp.intel.com ([169.254.4.108]) with mapi id 14.03.0319.002; Fri, 6 Oct 2017 15:50:35 +0100 From: "Dumitrescu, Cristian" To: Adrien Mazarguil CC: "dev@dpdk.org" , "thomas@monjalon.net" , "Wu, Jingjing" , "hemant.agrawal@nxp.com" , "jerin.jacob@caviumnetworks.com" , "Singh, Jasvinder" Thread-Topic: [PATCH V2 1/5] ethdev: add new flow action for metering and policing Thread-Index: AQHTPqs122kDek/o40aukkw9J/it+qLW5z6A Date: Fri, 6 Oct 2017 14:50:35 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D891267BACAFEB@IRSMSX108.ger.corp.intel.com> References: <1503705973-80742-2-git-send-email-cristian.dumitrescu@intel.com> <1507208974-180500-1-git-send-email-cristian.dumitrescu@intel.com> <1507208974-180500-2-git-send-email-cristian.dumitrescu@intel.com> <20171006135758.GD3871@6wind.com> In-Reply-To: <20171006135758.GD3871@6wind.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 V2 1/5] ethdev: add new flow action for 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: Fri, 06 Oct 2017 14:50:39 -0000 > -----Original Message----- > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com] > Sent: Friday, October 6, 2017 2:58 PM > To: Dumitrescu, Cristian > Cc: dev@dpdk.org; thomas@monjalon.net; Wu, Jingjing > ; hemant.agrawal@nxp.com; > jerin.jacob@caviumnetworks.com; Singh, Jasvinder > > Subject: Re: [PATCH V2 1/5] ethdev: add new flow action for metering and > policing >=20 > On Thu, Oct 05, 2017 at 02:09:30PM +0100, Cristian Dumitrescu wrote: > > Metering and policing action typically sits on top of flow classificati= on, > > which is why MTR objects are enabled through a newly introduced flow > > action. > > > > The configuration of MTR objects is done in their own namespace (rte_mt= r) > > within the librte_ether library. The MTR object is hooked into ethdev R= X > > processing path using the "meter" flow action. > > > > Signed-off-by: Cristian Dumitrescu >=20 > Looks good, one minor comment about the METER action semantics before > acking > this patch, see below. >=20 > > --- > > doc/guides/prog_guide/rte_flow.rst | 24 ++++++++++++++++++++++++ > > lib/librte_ether/rte_flow.h | 22 ++++++++++++++++++++++ > > 2 files changed, 46 insertions(+) > > > > diff --git a/doc/guides/prog_guide/rte_flow.rst > b/doc/guides/prog_guide/rte_flow.rst > > index 662a912..6b9cdc2 100644 > > --- a/doc/guides/prog_guide/rte_flow.rst > > +++ b/doc/guides/prog_guide/rte_flow.rst > > @@ -1354,6 +1354,30 @@ rule or if packets are not addressed to a VF in > the first place. > > | ``vf`` | VF ID to redirect packets to | > > +--------------+--------------------------------+ > > > > +Action: ``METER`` > > +^^^^^^^^^^^^^^^^^ > > + > > +Applies a stage of metering and policing. > > + > > +The metering and policing (MTR) object has to be first created using t= he > > +rte_mtr_create() API function. The ID of the MTR object is specified a= s > > +action parameter. One or several meter actions can be added to the sam= e > > +flow. More than one flow can use the same MTR object through the > meter > > +action. The MTR object can be further updated or queried using the > > +rte_mtr* API. >=20 > rte_flow is currently documented [1] as ignoring several actions of the s= ame > kind in a given rule, in which case only the last one is taken into > account. It's a deliberate design choice to simplify implementation, whic= h > I now think wasn't such a good idea after all. >=20 > I'm therefore not opposed to remove this restriction globally, however in > that case rte_flow documentation must be modified and PMDs reworked to > implement the new behavior (failing by default when encountering multiple > actions of the same time instead of ignoring them). It's probably a littl= e > late to do this now though. >=20 > So my suggestion for the time being is to not describe what happens when > several MTR actions are provided. We'll keep this for the next overhaul o= f > rte_flow (some other changes are already planned). Hi Adrian, Done in V3 just sent. Thanks, Cristian >=20 > [1] http://dpdk.org/doc/guides/prog_guide/rte_flow.html#actions >=20 > -- > Adrien Mazarguil > 6WIND