[openib-general] rdma_cm branch

[Or Gerlitz]

Sean Hefty wrote:
> Steve Wise wrote:
>> What is the status of the rdma_cm branch in Roland's infiniband.git
>> tree?  It doesn't have the iwarp stuff in it.  I'm wondering if it can
>> be merged with the 2.6.19 stuff to create a branch that was iwarp + ucma
>> support?  Or is that a dumb idea?
> 
> 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.
> 
> 3.  There's been requests for an rdma_cm branch that includes UD QP / multicast.
> 
> The cleanest solution from an ABI perspective is to merge multicast support 
> before the ucma; however, I'm not sure that makes the most sense for merging 
> upstream.  Thoughts?

Since the ucma will not make it for the 2.6.19 feature merge window, why 
not target both the ucma and the cma ud/ud-mulitast support for 2.6.20?

This way you would be doing one big ABI change and would not carry this 
HUGE svn/git diff.

As I have mentioned in the other thread, once it would make sense from 
your schedule to do the patch preparation work, it would be good to push 
it into the for-2.6.20 branch of Roland's tree from where it can go to 
the -mm tree so people can start testing it.

Once the code is in the for-2.6.20 branch, it would be also possible to 
include it in OFED 1.2 release which is expected on December this year.

Or.