> Since SRQ is not a required function in the IB spec we never addressed that > issue in the RFC along with UC. > > ...
Since SRQ is almost transparent wire-protocol-wise, RFC probably does not have to say anything about it. But I wonder why do you say this about UC which is explicitly documented in the spec. > If you really want to start splitting up which layer has part of the decision > on how to connect, then you need to propose a totally different RFC. > > ... I hear an architect speaking :) You seem to use the term layer in the OSI model sense, while Roland is just speaking about code organisation. We haven't stopped developing ipoib, so duplicating the controlling logic is a problem for us: both performance and maintainance wise. Abstracting the SRQ/nonSRQ issue out, by implementing a set of functions that can work on top of either SRQ or a pool of QPs is the proposed solution. -- MST _______________________________________________ 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
