From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 033BD1B684 for ; Fri, 13 Oct 2017 14:27:02 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Oct 2017 05:26:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.43,371,1503385200"; d="scan'208";a="1230409260" Received: from irsmsx154.ger.corp.intel.com ([163.33.192.96]) by fmsmga002.fm.intel.com with ESMTP; 13 Oct 2017 05:26:50 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.167]) by IRSMSX154.ger.corp.intel.com ([169.254.12.83]) with mapi id 14.03.0319.002; Fri, 13 Oct 2017 13:26:49 +0100 From: "Dumitrescu, Cristian" To: "Mcnamara, John" , "dev@dpdk.org" CC: "thomas@monjalon.net" , "adrien.mazarguil@6wind.com" , "Wu, Jingjing" , "hemant.agrawal@nxp.com" , "jerin.jacob@caviumnetworks.com" , "Singh, Jasvinder" Thread-Topic: [dpdk-dev] [PATCH V3 4/5] doc: ethdev traffic metering and policing api Thread-Index: AQHTPrHzcmTrCTBhpUOzKgcDf9XlN6LgRz6AgAF4V+A= Date: Fri, 13 Oct 2017 12:26:49 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D891267BAD0BB5@IRSMSX108.ger.corp.intel.com> References: <1507208974-180500-2-git-send-email-cristian.dumitrescu@intel.com> <1507301136-131382-1-git-send-email-cristian.dumitrescu@intel.com> <1507301136-131382-5-git-send-email-cristian.dumitrescu@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH V3 4/5] doc: ethdev traffic metering and policing api 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, 13 Oct 2017 12:27:03 -0000 > -----Original Message----- > From: Mcnamara, John > Sent: Thursday, October 12, 2017 3:59 PM > To: Dumitrescu, Cristian ; dev@dpdk.org > Cc: thomas@monjalon.net; adrien.mazarguil@6wind.com; Wu, Jingjing > ; hemant.agrawal@nxp.com; > jerin.jacob@caviumnetworks.com; Singh, Jasvinder > > Subject: RE: [dpdk-dev] [PATCH V3 4/5] doc: ethdev traffic metering and > policing api >=20 >=20 >=20 > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Cristian > Dumitrescu > > Sent: Friday, October 6, 2017 3:46 PM > > To: dev@dpdk.org > > Cc: thomas@monjalon.net; adrien.mazarguil@6wind.com; Wu, Jingjing > > ; hemant.agrawal@nxp.com; > > jerin.jacob@caviumnetworks.com; Singh, Jasvinder > > > > Subject: [dpdk-dev] [PATCH V3 4/5] doc: ethdev traffic metering and > > policing api > > > > Add new section in the Programmer Guide for the ethdev traffic metering > > and policing (MTR) API. > > > > Signed-off-by: Cristian Dumitrescu >=20 >=20 > Thanks for the well written doc. Some comments below. >=20 >=20 > > --- > > +Traffic Metering and Policing (MTR) API > > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Leave out the acronym from the title. It is explained in the overview. >=20 > > +The processing done for each input packet hitting an MTR object is: > > +* Traffic metering: The packet is assigned a color (the meter output > > + color) based on the previous traffic history reflected in the > > + current state of the MTR object, according to the specific traffic > > + metering algorithm. The traffic metering algorithm can typically wor= k > > + in color aware mode, in which case the input packet already has an > > + initial color (the input color), or in color blind mode, which is > > + equivalent to considering all input packets initially colored as gre= en. > > +* Policing: There is a separate policer action configured for each > > +meter > > + output color, which can: > > +.. Drop the packet. > > +.. Keep the same packet color: the policer output color matches the > > + meter output color (essentially a no-op action). > > +.. Recolor the packet: the policer output color is set to a different >=20 > This section throws several doc build errors. Bullet lists need to have > a blank line before them and the second level indentation isn't correct h= ere. >=20 > It should be something like this: >=20 >=20 > The processing done for each input packet hitting an MTR object is: >=20 > * Traffic metering: The packet is assigned a color (the meter output colo= r) > based on the previous traffic history reflected in the current state of= the > MTR object, according to the specific traffic metering algorithm. The > traffic metering algorithm can typically work in color aware mode, in w= hich > case the input packet already has an initial color (the input color), o= r in > color blind mode, which is equivalent to considering all input packets > initially colored as green. >=20 > * Policing: There is a separate policer action configured for each meter > output color, which can: >=20 > * Drop the packet. >=20 > * Keep the same packet color: the policer output color matches the mete= r > output color (essentially a no-op action). >=20 > * Recolor the packet: the policer output color is set to a different co= lor > than the meter output color. The policer output color is the output c= olor > of the packet, which is set in the packet meta-data (i.e. struct > ``rte_mbuf::sched::color``). >=20 > * Statistics: The set of counters maintained for each MTR object is > configurable and subject to the implementation support. This set includ= es > the number of packets and bytes dropped or passed for each output color= . >=20 >=20 Thanks, John, incorporated in V4 just sent.