| Message ID | 1463649827-17897-1-git-send-email-bala.manoharan@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
On Thu, May 19, 2016 at 4:23 AM, Balasubramanian Manoharan < bala.manoharan@linaro.org> wrote: > Adds documentation for packet drop policy and Error Class of service > > Signed-off-by: Balasubramanian Manoharan <bala.manoharan@linaro.org> > --- > 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 > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp >
On 20 May 2016 at 05:05, Bill Fischofer <bill.fischofer@linaro.org> wrote: > > > On Thu, May 19, 2016 at 4:23 AM, Balasubramanian Manoharan > <bala.manoharan@linaro.org> wrote: >> >> Adds documentation for packet drop policy and Error Class of service >> >> Signed-off-by: Balasubramanian Manoharan <bala.manoharan@linaro.org> >> --- >> 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 >> lng-odp@lists.linaro.org >> https://lists.linaro.org/mailman/listinfo/lng-odp > >
On Fri, May 20, 2016 at 5:48 AM, Bala Manoharan <bala.manoharan@linaro.org> wrote: > On 20 May 2016 at 05:05, Bill Fischofer <bill.fischofer@linaro.org> wrote: > > > > > > On Thu, May 19, 2016 at 4:23 AM, Balasubramanian Manoharan > > <bala.manoharan@linaro.org> wrote: > >> > >> Adds documentation for packet drop policy and Error Class of service > >> > >> Signed-off-by: Balasubramanian Manoharan <bala.manoharan@linaro.org> > >> --- > >> 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. > > > > >> > >> +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. > > 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 > >> lng-odp@lists.linaro.org > >> https://lists.linaro.org/mailman/listinfo/lng-odp > > > > >
On 20 May 2016 at 20:11, Bill Fischofer <bill.fischofer@linaro.org> wrote: > > > On Fri, May 20, 2016 at 5:48 AM, Bala Manoharan <bala.manoharan@linaro.org> > wrote: >> >> On 20 May 2016 at 05:05, Bill Fischofer <bill.fischofer@linaro.org> wrote: >> > >> > >> > On Thu, May 19, 2016 at 4:23 AM, Balasubramanian Manoharan >> > <bala.manoharan@linaro.org> wrote: >> >> >> >> Adds documentation for packet drop policy and Error Class of service >> >> >> >> Signed-off-by: Balasubramanian Manoharan <bala.manoharan@linaro.org> >> >> --- >> >> 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 >> >> lng-odp@lists.linaro.org >> >> https://lists.linaro.org/mailman/listinfo/lng-odp >> > >> > > >
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 +odp_pktio_error_cos_set(). All the packets received with error from this +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. +Multiple odp_pktio instances (_i.e.,_ multiple ports) may each have their own +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 +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. + +During creation of the Class of service if the pool or queue is set as INVALID +using ODP_POOL_INVALID or ODP_QUEUE_INVALID field then the packets received in +the specific CoS gets dropped by the implementation. + +=== 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:
Adds documentation for packet drop policy and Error Class of service Signed-off-by: Balasubramanian Manoharan <bala.manoharan@linaro.org> --- doc/users-guide/users-guide-cls.adoc | 29 +++++++++++++++++++++++++++-- 1 file changed, 27 insertions(+), 2 deletions(-)