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

[Mcnamara, John]

> -----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.