[openib-general] rdma_cm branch

[Or Gerlitz]

Sean Hefty wrote:
> I'm currently working on moving the rdma_cm code that's in svn forward to what's 
> upstream.  (I was just typing a message on this...)  My plan is to ask Roland to 
> host one, maybe two, branches in the infiniband.git tree.  Here are the main 
> pieces missing from the kernel:
> 
> 1.  We need to add rdma_establish() and expose the rdma_conn_param values as 
> part of the connection event.  I'm working on a patch for the latter.
> 
> 2.  We need a ucma branch.  To merge upstream, it makes sense to include item 1 
> first, but this leads to a conflict with the OFED releases.  OFED ABI version 1 
> includes RC QP support, but without item 1 changes, and SVN ABI version 2 
> includes multicast support.

Can you clarify what do you mean "(ABI) conflict with OFED releases"?

Is an issue with someone wishing to work with OFED user space and IB 
code from upstream kernel?

The approach i suggest is: it makes sense to take some care not to 
create too much non working scenarios... however the upstream push 
process must **not** be restricted by the existence of OFED.

My understanding is that libibverbs and ib_uverbs driver development (eg 
the exclusion of libibverbs 1.1 from OFED 1.1) follow this approach, and 
it would be good to apply it also on librdmacm.

Specifically, can you push rhe rdma_establish() ***kernel*** API support 
which was integrated into OFED 1.1 as a bug fix for 2.6.19 ?

Note that doing so is a must to have IB ULPs which are not upstream nor 
part of OFED -  RDS, Lustre's o2ibnld, NFSoRDMA, iSER being able to 
compile against both OFED and IB kernel code.

Else you create a conflict which places the kernel IB code in a second 
place relative to OFED.

Or.