On 20 May 2016 at 20:11, Bill Fischofer <[email protected]> wrote: > > > On Fri, May 20, 2016 at 5:48 AM, Bala Manoharan <[email protected]> > wrote: >> >> 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. > > > It was changed to Detect since Discarding is only one of possible actions > you might do upon detection (the other being marking). I'd therefore > rephrase this in that context. Perhaps: > > ...drop policy of the associated pool, _i.e.,_ depending on a discard action > following Random Early Detect.
Usually marking is done in egress not during classification. The only operation we support in classification during a pool reaching a high threshold is to randomly discard the packet or stall the packet based on the drop policy. > >> >> >> > >> >> >> >> +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. > > > A doc change is all we can do for Monarch. However we should revisit this in > Tiger Moth in the context of whether we want or need to add explicit support > for lossless Ethernet that uses class-based pauses to guarantee that pools > can never run dry. That's one of the reasons I added watermarks to the pool > internals in odp-linux. Yes. We need to have a formal discussion about drop policies supported by different hardwares. I will send a proposal for additional drop policies. Regards, Bala > > >> >> >> 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
