[ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCP ports from the host TCP port space.

[Sean Hefty]

> If we get rid of the rdma_cm specific port spaces, do we then reduce the 
>  valid possible spaces to just TCP and UDP?  Or what?  In the sockets 
> paradigm, the socket is explicitly bound to a protocol space when its 
> created (based on the protocol id).  Do you think we need to change the 
> rdma_cm_id to have such a concept?  IE when you create the cm_id, you 
> say your intended QP type or port space?  The current API lends itself 
> to somone incorrectly choosing a port space, by the way.

Currently, the RDMA port space implies the QP type (RC or UD).  We're 
not tied to any specific protocol when we create the rdma_cm_id, since 
we don't know what type of RDMA device we'll end up using.  So, I don't 
think we want users to specify a protocol.

> But should we really change the API that drastically?  Or just keep the 
> port spaces and make PS_TCP share the host's port space.

I don't want to break the user space API, if it can be helped.  SDP is 
kind of a problem, in that the rdma_cm needs to distinguish between SDP 
as a user, versus someone using RDMA_PS_TCP.  SDP maps between the RDMA 
port space and real TCP port space.  I need to get some details on how 
SDP uses the rdma_cm, like whether it uses wild card port numbers.

> Maybe the rdma-cm port spaces should really be IB, IWARP, or BOTH.  IB 
> has its own port space, and IWARP or BOTH gets the TCP port space.

I thought about doing something like this, but I'm not sure there would 
be much use of just IB or just iWarp, when the user can specify both. 
  I even considered pushing the problem into the iWarp CM, but that 
seems like a more complex implementation with no benefit unless there 
are users of just an IB port space.

At this point, my thoughts are to take your original patch, remove the 
rdma_cm port space structures and functions, and figure out how to 
handle SDP.

- Sean