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