Steve Wise
Sat, 04 Aug 2007 08:50:30 -0700
Sean Hefty wrote:
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.
Lemme know how I can help. I certainly can test any patches on my 8 node iwarp cluster.
Steve. _______________________________________________ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general