On 10/5/06, Sean Hefty <[EMAIL PROTECTED]> wrote: > > I'm confused -- how does this fix anything? I don't see any callers > > of the new rdma_establish() function ?? > > This was submitted at the request of Michael and Or, so I'll let them comment. > There are no in tree passive side users of the rdma_cm, so passive side calls > are unused (rdma_listen, rdma_accept, rdma_establish). > > I have no issues deferring this patch until a user is added (which I hope will > be 2.6.20).
My understanding is that the only in tree usage of the passive side calls in 2.6.20 would be the rdma cm user space support. Generally speaking, I have no problems deferring this to 2.6.20, however, the problem is that this API is exposed by the OFED's CMA. Hence there is a kernel API diff between OFED to the kernel IB code. This puts the developers of ULPs who are CMA consumers (iSER target, RDS, Lustre, NFSoRDMA, SDP) in a problem, since they can't have the same code base for OFED and the kernel. My take on that as i expressed it to Sean over the "rdma_cm" thread, is that basically, either the IB kernel maintainers (Roland and Sean) decide to push it into 2.6.19 (eg under the justification that rdma_listen and rdma_accept are already there) or demand taking it out from OFED 1.1 as it violates the "don't put a future kernel IB code in second place relative to OFED" guideline. Or. _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general