On 9/5/07, Sean Hefty <[EMAIL PROTECTED]> wrote: > >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.
Already is a diag tool (saquery) which does this. > (Why limit it to QoS only then?) Only because it was the topic of discussion and the most "interesting" capability to query. > 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. Sure if they are somehow tied together. > >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. Indeed and maintaining QoS across SM failover is a hard problem which is left to the individual SM implementations (as are other similar failover issues). -- Hal > >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
