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
_______________________________________________
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
