>Before enhancing the rdma-cm to support the full feature set of the IB >CM, something which I personally don't see the actual need for (but I >will be happy to get educated what applications will or can migrate to >rdma-cm once this is implemented), how about trying to allow for reduced >QoS scheme also when the entity that resolved this patch didn't >consulted with the SA?
I think this really needs to be discussed wrt the implementation of the entity providing the path records. >IB QoS is based on the query providing the <SGID, DGID, PKEY, SID, TOS> >tuple and the SA returning a <SLID, DLID, SL, MTU, ....> QoS tuple. Now >I'd like to see how can we let the application / querying middleware to >take advantage of the knowledge on what partition it runs and use the SL >associated with the IPv4 (e.g AF_INET rdma-cm ID's) IPoIB broadcast >group. This way, one can still program a QoS scheme at the SA which is >based on partitions. I think what's needed is a way for the SA to distribute QoS information to the end nodes, so that the decisions can be made locally. If someone wants some sort of dynamic QoS management and is happy using a small cluster, then they can disable any local SA entities and contact the SA directly. In the case of ACM, the pkey is embedded in the MGID. 'Something' could tell the SA to create ACM multicast groups using a specific SL for a given MGID or pkey in the join request. That SL would be distributed to the end nodes when they joined their groups. >Looking on mckey, the user space code (e.g ACM), could just do rdma_bind >to an IP address of an IPoIB NIC that uses this partition and then >rdma_join to an unmapped multicast address which correspond to the >broadcast group, take the SL and leave the group, makes sense? The entity that provides the path records cannot depend on calling into the librdmacm. The dependency needs to go the other way. - Sean -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
