From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Mcnamara, John" Subject: Re: [PATCH V3 4/5] doc: ethdev traffic metering and policing api Date: Thu, 12 Oct 2017 14:59:27 +0000 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "thomas@monjalon.net" , "adrien.mazarguil@6wind.com" , "Wu, Jingjing" , "hemant.agrawal@nxp.com" , "jerin.jacob@caviumnetworks.com" , "Singh, Jasvinder" To: "Dumitrescu, Cristian" , "dev@dpdk.org" Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 2AC131B3B2 for ; Thu, 12 Oct 2017 16:59:32 +0200 (CEST) In-Reply-To: <1507301136-131382-5-git-send-email-cristian.dumitrescu@intel.com> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > -----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 >=20 > Add new section in the Programmer Guide for the ethdev traffic metering > and policing (MTR) API. >=20 > Signed-off-by: Cristian Dumitrescu Thanks for the well written doc. Some comments below. > --- > +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 Leave out the acronym from the title. It is explained in the overview. > +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 work > + 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 green= . > +* 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 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 her= e. It should be something like this: 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 t= he MTR object, according to the specific traffic metering algorithm. The traffic metering algorithm can typically work in color aware mode, in whi= ch 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 green. * 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 colo= r than the meter output color. The policer output color is the output col= or of the packet, which is set in the packet meta-data (i.e. struct ``rte_mbuf::sched::color``). * Statistics: The set of counters maintained for each MTR object is configurable and subject to the implementation support. This set includes the number of packets and bytes dropped or passed for each output color.