>It's not a requirement to wait for the QoS determination of the SA >before issuing the SA PR requests.
It sounds like you're suggesting that the end nodes just automatically gather and print the capabilities of the SA. (Why limit it to QoS only then?) An administrator could run a separate tool to gather this information, rather than it being done on all nodes automatically. If the QoS determination is tied into the behavior of the PR queries, then I think you end up either queuing the requests or responses somewhere. >Failover is pretty straightforward. The same query is made when SM LID changes. Yes - but existing paths that are in use may now suddenly provide or no longer provide QoS. >Will the QoS code handle the new error status code which suggests a >different QoSClass or is it currently being handled like other errors >? Guess that could be a separate patch. This would be a separate patch, and is left up to each ULP at the moment. For ipoib, I used the TClass, so the new QoS fields are not an issue. For the rdma_cm, the QoS info is set by the user when using IPv4 addressing, so they would need to take appropriate action. - Sean _______________________________________________ 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
