> It is not clear if anything is better yet, but instead you have to go back > to the IPoIB-CM RFC 4755 that we wrote. In the spec you will see that the > approach for this driver is to have the IPoIB driver select the most > appropriate method of connecting. If RC was not available then UD was > used. You can extend that to UC mode as Michael proposed, as long as you > allow selecting the most appropriate method of connection. By pushing the > issue of SRQ or not SRQ to the driver you have broken the IPoIB-CM > original design. Since SRQ was not a required function in the IB spec we > never addressed that issue in the RFC along with UC. I think we can agree > that adding UC is a good thing and follows the approach in the original > spec. Including SRQ as one of the tests for the best possible connection > method follows this same approach.
> .... I can't really follow this. We're talking about the internal implementation inside the Linux kernel, which I really hope that an IETF RFC does not address at all. We surely intend to follow the RFC, and if we run into problems because the RFC was written without any implementation experience, then we'll work to correct those problems through a new IETF document. It makes perfect sense for ehca systems to be able to use IPoIB CM. I understand that current ehca HW doesn't natively support SRQs. The only question is how to implement IPoIB CM for ehca systems, and we have to weigh tradeoffs like avoiding code duplication vs the additional cost of branches on the data path. - R. _______________________________________________ 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
