On Thu, Mar 25, 2010 at 08:56:23PM -0700, Sean Hefty wrote: > >>Is there any reason the port space has to be known when the cm_id is > >>created but before bind? > > > >No - but it is still required for transport neutrality. rdma_create_id() > >simply stores the value. > > To correct this slightly, a user can call listen after calling create_id > without > calling bind. The bind is done internally to listen. > > The port space really should be indicated at creation time. If we can agree > on > that, then the kernel simply needs to decide how to handle AF_IB at bind time.
I still think AF_IB should not have any port space other than RDMA_PS_IB - since it is functionally inclusive of all the other cases. > These patches handle it by setting the well known portion of the SID and > acting > on the other bits based on them being set. The mask is unused. For the > existing port spaces, we can leave this, or require the user provide a > SID/mask > that is consistent with the chosen port space. See, to me this is very not nice. The address is specified with a SID/mask, having the kernel ignore the mask and overwrite bits in the SID makes no sense as an API. > For RDMA_PS_IB, I think the flow that you outlined in your other email makes > sense. Let RDMA_PS_IB cover the entire SID range. When the SID/mask fall > into > an existing port space, it needs to reserve a port from within that port space > to avoid collisions. Right :) I just don't understand why you think AF_IB/RDMA_PS_TCP has to be a supported combination. Is there some use case you see where having RDMA_PS_TCP/UDP work with AF_IB is an advantage? Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
