[openib-general] [PATCH] 2.6.19 rdma_cm: add rdma_establish call to connect if RTU is lost

[Or Gerlitz]

On 10/5/06, Sean Hefty <mshefty at ichips.intel.com> 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.