On Tue, Oct 20, 2009 at 12:13:03PM -0700, Sean Hefty wrote: > >> rdma_bind_addr fills in the service id according RDMA IP CM service > >> annex. > > > >Hm? If the sockaddr_ib contains the service ID why override it in the > >kernel? > > > >The AF_IB/PS_IB flow in the kernel side must just use straight service > >IDs. > > I agree. But we can still support AF_IB/PS_TCP by simply assigning > the service ID correctly. rdma_bind_addr only needs to fill in a > service id if one is not given. This should enable
'one is not given' == 0 service ID? Is there any reason to ever use AF_IB/PS_TCP on the listening side? What functional difference are you imagining compared to listening on AF_INET/PS_TCP? > interoperability. I realize that IB doesn't have the concept of a > service ID for the active side of a connection, but the RDMA IP CM > Service header carries the source port. And rdma_bind_addr is > called by rdma_resolve_addr, so it needs to be updated. Hmm, yes, messy.. > Even once PS_IB is added, we need to make sure that it doesn't collide with > PS_TCP at the IB service ID level, or IB will be in the same situation that > iWarp is in with space collisions. I thought there was already a single service ID registration list that was shared between RDMA CM and IB CM? Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
