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