[openib-general] QoS RFC

[Asgeir Eiriksson]

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: openib-general-bounces at openib.org
[mailto:openib-general-bounces at openib.org] On Behalf Of Eitan Zahavi
Sent: Tuesday, May 30, 2006 7:41 AM
To: openib-general at openib.org
Cc: Nimrod Gindi; Roland Dreier
Subject: [openib-general] QoS RFC

 

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 <eitan at mellanox.co.il>

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.


< cut to end of original email>

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20060531/0243ba68/attachment.html>