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

[Steve Wise]

Sorry guys, I haven't had time to catch up on this thread yet...

I'll try and answer you by EOB tomorrow.

Steve.


Sean Hefty wrote:
> 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.