[dpdk-dev] [PATCH V3 4/5] doc: ethdev traffic metering and policing api
Dumitrescu, Cristian
cristian.dumitrescu at intel.com
Fri Oct 13 14:26:49 CEST 2017
> -----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.
More information about the dev
mailing list