[ofa-general] QoS in RDMA CM: (was QoS RFC)

[Sean Hefty]

Steve,

Do you have any input with respect to how the RDMA CM selects and maps 
QoS (priority, traffic class, VLAN, flow label, etc.)?  (See below)

Hide the QoS selection under the current interface?  Use the IPv6 
flowinfo field?  Rely on destination port?  Input QoS through existing 
or new call?  Handle IPv4 and IPv6 addresses differently?  ???

- Sean

>> 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.)
> 
>> 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.