[ofa-general] QoS RFC

[Sean Hefty]

> 2.5. ULPs that use CM interface (like SRP) should have their own 
> pre-assigned Service-ID and use it while obtaining PR/MPR for
> establishing connections. The SA receiving the PR/MPR should match it
> against the policy and return the appropriate PR/MPR including SL,
> MTU and RATE.

We need to ensure that this can work without pre-assigned service IDs, 
or at least service IDs that are assigned within a fairly wide range, 
such as locally assigned IDs.

> 2.6. ULPs and programs using CMA to establish RC connection should 
> provide the CMA the target IP and Service-ID. Some of the ULPs might
> also provide QoS-Class (E.g. for SDP sockets that are provided the
> TOS socket option). The CMA should then use the provided Service-ID
> and optional QoS-Class and pass them in the PR/MPR request. The
> resulting PR/MPR should be used for configuring the connection QP.

The interface to the CMA needs to remain as transport independent as 
possible, and I am unsure of the transport independence of tying QoS to 
the destination port number.  (I'm not disagreeing; I'm just not sure at 
the moment it's the right approach.)

> PathRecord and MultiPathRecord enhancement for QoS: As mentioned
> above the PathRecord and MultiPathRecord attributes should be 
> enhanced to carry the Service-ID which is a 64bit value, which has
> been standardized by the IBTA. A new field QoS-Class is also
> provided. A new capability bit should describe the SM QoS support in
> the SA class port info. This approach provides an easy migration path
> for existing access layer and ULPs by not introducing new set of
> PR/MPR attribute.

Has any thought been given to how to make this scale?

> 5. CMA features ----------------
> 
> The CMA interface supports Service-ID through the notion of port
> space as a prefixes to the port_num which is part of the sockaddr
> provided to rdma_resolve_add(). What is missing is the explicit
> request for a QoS-Class that should allow the ULP (like SDP) to
> propagate a specific request for a class of service. A mechanism for
> providing the QoS-Class is available in the IPv6 address, so we could
> use that address field. Another option is to implement a special 
> connection options API for CMA.
> 
> Missing functionality by CMA is the usage of the provided QoS-Class
> and Service-ID in the sent PR/MPR. When a response is obtained it is
> an existing requirement for the CMA to use the PR/MPR from the
> response in setting up the QP address vector.

The most natural function to specify additional QoS parameters would be 
rdma_resolve_route.

- Sean