On Mon, Mar 29, 2010 at 12:01:07PM -0700, Roland Dreier wrote: > > > The rdma_cm might be able to support this if the port space were > separated based > > > on the address family, depending on how PS IB ends up. > > > > I think separate port spaces is the correct solution. > > This gets a bit tricky -- for normal IP stuff, there's the "bindv6only" > sysctl (and the IPV6_V6ONLY socket option). Without that, you can't > bind an IPv4 socket to the same port as an IPv6 socket, since the IPv6 > socket will accept IPv4 connections via an v4->v6 mapped address. (You > can look at inet_csk_bind_conflict() to see the full complexity of the > checking done when binding an IPv4 socket)
Yeah, exactly, it is very complex and there is a real need for things pretending to be IP to capture all this subtlety. The details can't just be skipped over, people will notice :( Though, I'm also not entirely certain that NFS-RDMA is right to bind to both AFs, generally speaking on Linux for a multi-protocol app you only want to bind to v6 addresses.. Or is it using IPV6_V6ONLY or alike? > I wonder what the right way from the RDMA CM to stay close to Linux > sockets semantics without adding too much horror is. (Adding Jason to > the CC list since he usually has an opinion about things like this :) Clearly the best way is to figure out some way to work with the existing routines in the kernel. This stuff is complex and duplicating all of it in rdma_cm would be annoying.. To match the semantics each CM ID would still register to one SID but an incoming connection request on a v4 PF SID could be matched to a v6 SID, etc. I don't think new port spaces in the API are desirable. 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
