Hermant, thank you for your comments.
Some of your remarks refer to an Ingress API, which is not the topic of this proposal. In other words, whatever you feel should be included in ingress processing, should go in a separate discussion related to the ODP Classification API. With respect to logical ports, and how they relate to PKTIO, this is also a topic outside of the Egress API discussion, since PKTIO have been previously defined in the API. Hierarchical scheduling is (as noted in the document) a topic deferred to a later stage, where the proposal API, if accepted, can be augmented. As much as we value the feedback of all current and potential implementers of ODP, both members and non-members, it would greatly streamline the process if the comments are directed at a specific section of the API, and may ideally contain concrete counter-proposals or change requests, rather than lengthy laundry lists of features one may desire in a data-plane application. To that end, if you first take the time to study all of the currently defined and proposed ODP API sections, and then offer remarks, or improvement proposals, each directed at a specific section of the API, you will be helping to move the process along. It would be even more beneficial to ODP if such remarks were made while engaging in the implementation of ODP on a specific platform, e.g. SoC. Thanks, - Leo ________________________________ From: Agrawal Hemant <[email protected]> Sent: Tuesday, May 26, 2015 4:28 AM To: Rosenboim, Leonid; [email protected] Subject: RE: [ODP] Egress API proposal Hi Leo, I see some disconnect with proposed APIs. First of all, we need to follow the IETF Diffserv model, w.r.t. what QoS functions are done on which processing leg. The DiffServ APIs were extensively discussed in the past and agreed upon by industry in NPF forum. Please refer to: http://www.oiforum.com/public/documents/Diffserv_IA.pdf In the current proposal, everything is done in the context of egress. · IETF model differs, some functions are to be ingress. o E.g. SRTCM and TRTCM policing and associated actions of drop/remark/color is done in the ingress as part of admission-control, based on classifier lookups. o This coloring is used § to allocate buffers at the ingress § to do congestion control at the ingress, while enqueueing the packet. § to do congestion control at the egress. o Note that rate-limiting on a per-queue level at the egress is also done at times, (like Cisco does) § But this is an exception, rather than the rule. § Policing and/or remarking at the egress is not supported in many hardware. - Congestion control missing o based on tail drop or WRED o It can also be done based on congestion groups or o buffer-pool-depletion thresholds. - Congestion feedback mechanism is missing o Congestion groups (of associated queues) or buffer-pool-depletion. - For hierarchical scheduling o We need to have a concept of logical ports, not just PKTIO. § Each logical port has a set of queues, which are fed through a scheduler (priority + WFQ mix) § Each queue of a logical port has a rate-limiter, and represents a traffic class. § Each logical port has a shaper. § Each logical port is supposed to represent a customer (e.g. for aggregation edge router) o A group of logical ports is then fed via a scheduler to the physical port (PKTIO), and the physical port also has a shaper. - Some customers may want to do the QoS processing in SW o Need to dedicate separate core(s)/thread(s) for the QoS stage of the pipeline processing. o Need to have multiple scheduler groups - I believe it is important to build a model first, and then define API o Define each of the objects in the model § Physical port § Classifier § Policer/marker § Buffer-pool § Dropper/congestion-group § Ingress, Egress queues § Schedulers § Shapers § Logical ports o Define their properties § E.g. Policer has · Algo - token-bucket, SRTCM, TRTCM · Rates - CIR, CBS, EIR, EBS etc. · Actions - remark - DSCP, TOS, P-bit, color - red/green/yellow, drop. § E.g. Queue has · Type - SP or WFQ · Weight and/or Prio · Queue-depth · Associated rate-limiter · Associated congestion-group (and thresholds - WRED) o Define their relationship to each other § Ingress-chain: Physical-port == Classifier == Policer(s) == Buffer-pool (depletion) === Ingress-queue (congestion-group) === Ingress-scheduler === Application § Egress-chain: Policer == Egress-queue (congestion-group) === Egress-scheduler == Logical-port shaper === Egress-scheduler === Physical-port-shaper == Physical port == Buffer-pool (replenish) Regards, Hemant From: lng-odp [mailto:[email protected]] On Behalf Of Rosenboim, Leonid Sent: Tuesday, May 26, 2015 10:59 AM To: [email protected] Subject: [lng-odp] [ODP] Egress API proposal Hi all, Following is the current Egress API proposal document, Enjoy, - Leo https://docs.google.com/document/d/1gteeq4n0qwW_MZ7y0jRhDuQd_SiN2eZ0_VDtRkrJSxk/edit?usp=sharing? [https://lh4.googleusercontent.com/AuWjrwfY86CjB_KUL4c7jYXXRb8VWOKgqft_Gv_shHtQTpHWJja_SB0kNUBw6WcScfvkQw=w1200-h630-p]<https://docs.google.com/document/d/1gteeq4n0qwW_MZ7y0jRhDuQd_SiN2eZ0_VDtRkrJSxk/edit?usp=sharing> ODP_Egress_API_Proposal - Google Docs ODP Egress API The following document contains proposed API changes to current ODP, to incorporate advances egress configuration on platforms that support such capabilities. Background The following considerations are governing the proposal API changes outlined below: Objectives Following are the fu Read more...<https://docs.google.com/document/d/1gteeq4n0qwW_MZ7y0jRhDuQd_SiN2eZ0_VDtRkrJSxk/edit?usp=sharing> ________________________________ From: Bill Fischofer <[email protected]<mailto:[email protected]>> Sent: Friday, May 22, 2015 9:34 AM To: Bala Manoharan; Rosenboim, Leonid Cc: Raj Murali Subject: Egress API proposal Hi, We're getting requests to see the current proposal for the Egress API in advance of the June Sprint. Can you please post it to the ODP mailing list? Thanks. Bill
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
