[openib-general] rdma_cm branch

[Or Gerlitz]

Sean Hefty wrote:
> Or Gerlitz wrote:
>> 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?

> Yes - there could be issues there.

As long as OFED provides kernel IB code you need not support the above 
config.


>> 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.

> I agree with this.

cool.

>> 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 ?

> Yes, but I'd like a user of it to go in at the same time.

I don't think this is possible nor its required. The thing is that the 
only in-tree consumer of the cma code is the iser initiator which 
implements the active side of an rdma connection. As such it does not 
call rdma_accept() nor it can be modified to call rdma_establish(), so 
the _establish() call can be merged during bug fixes window similarly as 
the _accept() call has been merged during feature window.

If you find it problematic to merge it for 2.6.19 i think you should 
demand ***removing*** the rdma_establish() call from OFED 1.1 as this 
puts the kernel code in second place relative to OFED and violates 
another guideline: OFED uses ***kernel IB code***, where "kernel IB 
code" stands for code  that has been merged into Linus tree, or is at 
some branch of Roland's tree (or your tree when you have such...), or at 
the -mm tree etc.

Or.