[ofa-general] Re: [PATCH draft, untested] ehca srq emulation (for IPoIB CM)

[Roland Dreier]

 > 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.