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
