>> 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?
yes I'm guessing PS_IB would need to assign from the IB CM assigned range starting at 0x020::0 to avoid conflicts. >Is there any reason to ever use AF_IB/PS_TCP on the listening side? I don't think so. I was thinking of this combination on the active side in order to get the port number to place in the private data. >What functional difference are you imagining compared to listening on >AF_INET/PS_TCP? I hadn't thought about this, but making stuff up, I guess this could allow using the rdma_cm without ipoib running...? From IB's perspective, PS_TCP is just a specific subset of the service ID range. >> 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? Not really - the rdma cm constructs the service id, and the ib cm checks that it's usable, but not until listen is called. -- 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
