On Thu, May 19, 2016 at 4:23 AM, Balasubramanian Manoharan < [email protected]> wrote:
> Adds documentation for packet drop policy and Error Class of service > > Signed-off-by: Balasubramanian Manoharan <[email protected]> > --- > doc/users-guide/users-guide-cls.adoc | 29 +++++++++++++++++++++++++++-- > 1 file changed, 27 insertions(+), 2 deletions(-) > > diff --git a/doc/users-guide/users-guide-cls.adoc > b/doc/users-guide/users-guide-cls.adoc > index d2ba743..b158122 100644 > --- a/doc/users-guide/users-guide-cls.adoc > +++ b/doc/users-guide/users-guide-cls.adoc > @@ -109,7 +109,32 @@ pools. Multiple odp_pktio instances (i.e., multiple > ports) may each have their > own default odp_cos, or may share a odp_cos with other ports, based on > application requirements. > > -Packet Classification > +=== Error packet handling > + > +Any Error class of service is assigned to ingress port using the function > ...assigned to an ingress port > +odp_pktio_error_cos_set(). All the packets received with error from this > `odp_pktio_error_cos_set()`. > +specific ingress port are assigned to this error class-of-service. > +At minimum this error class-of-service must have a queue and a buffer pool > +assigned to it on platforms that support multiple packet buffer pools. > [For platforms that only support a single buffer pool, don't we still require that that buffer pool be specified?] > +Multiple odp_pktio instances (_i.e.,_ multiple ports) may each have their > own > odp_pktio seems awkward here. Multiple pktio instances... seems clearer. > +error class of service, or may share an error CoS with other ports, based > on > +application requirements. > + > +=== Packet dropping > + > +Each class of service has a `drop_policy` configured during creation. The > +valid value are ODP_COS_DROP_POOL and ODP_COS_DROP_NEVER. If the > `drop_policy` > +is set to ODP_COS_DROP_POOL then the packets assigned to the CoS follows > the > +drop policy of the associated pool _i.e.,_ depending on the Random Early > Discard > RED is now Random Early Dectect > +or any other configuration of the pool the packet might get dropped. If > the > +`drop_policy` is set to ODP_COS_DROP_NEVER then the drop policy of the > pool is > +ignored and the packet is never dropped by the implementation. > [What happens if the pool is exhausted?] > + > +During creation of the Class of service if the pool or queue is set as > INVALID > Inconsistent capitalization. You use class of service elsewhere so no need to capitalize class here. > +using ODP_POOL_INVALID or ODP_QUEUE_INVALID field then the packets > received in > +the specific CoS gets dropped by the implementation. > grammar: get (or more preferably, are) is correct here. Received isn't quite right here either. Suggested rephrase: ..then any packets assigned to the specified CoS are dropped... > + > +=== Packet Classification > > For each odp_pktio port, the API allows the assignment of a > class-of-service to > a packet using one of three methods: > @@ -136,7 +161,7 @@ destination or source port numbers, and appropriately > assign these packets a > class-of-service that maps to a higher priority queue, assuring voice > packets a > lower and bound latency. > > -Packet meta data Elements > +=== Packet meta data Elements > > Here are the specific information elements that are stored within the > packet meta data structure: > -- > 1.9.1 > > _______________________________________________ > lng-odp mailing list > [email protected] > https://lists.linaro.org/mailman/listinfo/lng-odp > _______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
