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

[Pradeep Satyanarayana]

Roland Dreier wrote:
>  > 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.
> 

In the absence of any further discussions about the IPoIB CM without SRQ
patches, I will incorporate Sean Hefty's comments and plan to resubmit
the patches, unless I hear something soon.

Pradeep