> -----Original Message----- > From: Mcnamara, John > Sent: Thursday, October 12, 2017 3:59 PM > To: Dumitrescu, Cristian <cristian.dumitre...@intel.com>; dev@dpdk.org > Cc: tho...@monjalon.net; adrien.mazarg...@6wind.com; Wu, Jingjing > <jingjing...@intel.com>; hemant.agra...@nxp.com; > jerin.ja...@caviumnetworks.com; Singh, Jasvinder > <jasvinder.si...@intel.com> > Subject: RE: [dpdk-dev] [PATCH V3 4/5] doc: ethdev traffic metering and > policing api > > > > > -----Original Message----- > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Cristian > Dumitrescu > > Sent: Friday, October 6, 2017 3:46 PM > > To: dev@dpdk.org > > Cc: tho...@monjalon.net; adrien.mazarg...@6wind.com; Wu, Jingjing > > <jingjing...@intel.com>; hemant.agra...@nxp.com; > > jerin.ja...@caviumnetworks.com; Singh, Jasvinder > > <jasvinder.si...@intel.com> > > 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 <cristian.dumitre...@intel.com> > > > Thanks for the well written doc. Some comments below. > > > > --- > > +Traffic Metering and Policing (MTR) API > > +======================================= > > 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 here. > > 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 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 color > than the meter output color. The policer output color is the output color > 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. > >
Thanks, John, incorporated in V4 just sent.
