|
Eitan Let’s assume for the moment (because
you’re presenting this under the OpenFabrics banner) that the capability
you describe below will be hidden behind wire protocol agnostic API that can be
used by IB HCA, Ethernet RNIC, etc. It is not clear from the description, but
I assume the arbiter you refer to below allows for traffic classes where a) the
bandwidth of the different flows within a particular class aggregate to a fixed
bandwidth, and also b) where each flow within a class has a fixed bandwidth,
e.g. where each flow corresponds to some type of fixed rate media stream. A QoS API should also needs have support
for flows with large RTT (Round Trip Times). Large RTT flows typically require
the sender to space the packets equally on the wire (referred to as pacing),
with the spacing interval being dynamically computed based on the RTT. It is
sufficient in this case to be able to set a pacing attribute through the API. Regards, Asgeir Eiriksson CTO Chelsio Communications From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eitan Zahavi Hi All Please find the
attached RFC describing how QoS policy support could be implemented in the OpenFabrics stack. Your comments are welcome. Eitan
RFC: OpenFabrics Enhancements for QoS Support
=============================================== Authors: . Eitan Zahavi <[EMAIL PROTECTED]> Date: .... May 2006. Revision: 0.1 Table of contents: 1. Overview 2. Architecture 3. Supported Policy 4. CMA functionality 5. IPoIB functionality 6. SDP functionality 7. SRP functionality 8. iSER functionality 9. OpenSM functionality 1. Overview ------------ Quality of Service requirements stem from the realization of I/O
consolidation over IB network: As multiple applications and ULPs share the
same fabric, means to control their use of the network resources are becoming a
must. The basic need is to differentiate the service levels provided to
different traffic flows. Such that a policy could be enforced and control each flow
utilization of the fabric resources. IBTA specification defined several hardware features and
management interfaces to support QoS: * Up to 15 Virtual Lanes (VL) could carry traffic in a
non-blocking manner * Arbitration between traffic of different VL is performed by a
2 priority levels weighted round robin arbiter. The arbiter is
programmable with a sequence of (VL, weight) pairs and maximal number of
high priority credits to be processed before low priority is served * Packets carry class of service marking in the range 0 to 15 in
their header SL field * Each switch can map the incoming packet by its SL to a
particular output VL based on programmable table VL=SL-to-VL-MAP(in-port,
out-port, SL) * The Subnet Administrator controls each communication flow
parameters by providing them as a response to Path Record query The IB QoS features provide the means to implement a DiffServ
like architecture. DiffServ architecture (IETF RFC2474 2475) is widely used today
in highly dynamic fabrics. This proposal provides the detailed functional definition for
the various software elements that are required to enable a DiffServ like
architecture over the OpenFabrics software stack.
|
_______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
