[dpdk-dev] [PATCH V3 4/5] doc: ethdev traffic metering and policing api

[Dumitrescu, Cristian]

> -----Original Message-----
> From: Mcnamara, John
> Sent: Thursday, October 12, 2017 3:59 PM
> To: Dumitrescu, Cristian <cristian.dumitrescu at intel.com>; dev at dpdk.org
> Cc: thomas at monjalon.net; adrien.mazarguil at 6wind.com; Wu, Jingjing
> <jingjing.wu at intel.com>; hemant.agrawal at nxp.com;
> jerin.jacob at caviumnetworks.com; Singh, Jasvinder
> <jasvinder.singh at intel.com>
> Subject: RE: [dpdk-dev] [PATCH V3 4/5] doc: ethdev traffic metering and
> policing api
> 
> 
> 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Cristian
> Dumitrescu
> > Sent: Friday, October 6, 2017 3:46 PM
> > To: dev at dpdk.org
> > Cc: thomas at monjalon.net; adrien.mazarguil at 6wind.com; Wu, Jingjing
> > <jingjing.wu at intel.com>; hemant.agrawal at nxp.com;
> > jerin.jacob at caviumnetworks.com; Singh, Jasvinder
> > <jasvinder.singh at 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.dumitrescu at 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.