On 20 May 2016 at 05:05, Bill Fischofer <[email protected]> wrote: > > > 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?]
Maybe the wording is confusing.. For platforms with only a single buffer pool the same pool will be assigned to all CoS but for platforms which support multiple buffer pools different pools can be assigned to different CoS. I will reword to remove the ambiguity in the next version. > >> >> +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 Actually in this context it is Random Early Discard since the packets are discarded when the pool reaches the high water mark. That's why I haven't used the acronym. > >> >> +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?] Drop policy can be of several types where DROP_NEVER can mean either to ignore the RED of the pool or the packet can also be stalled by the implementation even when the pool is exhausted. I believe we need to further refine the drop policy in the future to add additional parameter but for now maybe I will add that DROP_NEVER only ignores the RED properties of the pool. Regards, Bala > >> >> + >> +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
