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

[Steve Wise]

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

In the socket API, socket options describe what protocol they are 
intended for.  You can have options that are intended for IP or TCP and 
other protocol layers.

We could do some rdma_setopt() interface, and define both transport 
independent options and transport-specific options.  Then if there are 
features of qos that are only in IB, you can make them 
transport-specific options.  So an option struct may have a 
transport_type field...

Although I _think_ it will be a good thing to try and map 
transport-specific qos attributes to a univeral transport independent 
attribute.  But I'm not an expert on qos stuff...

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

Or a more generic rdma_setopt() that can be extensible for future 
options/attributes and not break the API...

My 2 cents.

Stevo.