> > > > I'm sure I had seen a previous email in this thread that > > > suggested using > > > > a userspace library to open a socket > > > > in the shared port space. It seems that suggestion was > > > dropped without > > > > reason. Does anyone know why? > > > > > > Yes, because it doesn't handle in-kernel uses (eg NFS/RDMA, > > > iSER, etc). > > > > The kernel apps could open a Linux tcp socket and create an RDMA > > socket connection. Both calls are standard Linux kernel architected > > routines. > > This approach was NAK'd by David Miller and others... > > > Doesn't NFSoRDMA already open a TCP socket and another for > > RDMA traffic (ports 2049 & 2050 if I remember correctly)? > > The NFS RDMA transport driver does not open a socket for the RDMA > connection. It uses a different port in order to allow both > TCP and RDMA > mounts to the same filer. > > > I currently > > don't know if iSER, RDS, etc. already do the same thing, but if they > > don't, they probably could very easily. > > > > Woe be to those who do so... > > > > > > > Does the neteffect NIC have the same issue as cxgb3 here? > What are > > > your thoughts on how to handle this? > > > > Yes, the NetEffect RNIC will have the same issue as > Chelsio. And all > > Future RNIC's which support a unified tcp address with Linux will as > > well. > > > > Steve has put a lot of thought and energy into the problem, but > > I don't think users & admins will be very happy with us in > the long run. > > > > Agreed. > > > In summary, short of having the rdma_cm share kernel port space, I'd > > like to see the equivalent in userspace and have the kernel > apps handle > > the issue in a similar way as described above. There are a few > > technical > > issues to work through (like passing the userspace IP address to the > > kernel), > > This just moves the socket creation to code that is outside > the purview > the kernel maintainers. The exchanging of the 4-tuple created with the > kernel module, however, is back in the kernel and in the maintainer's > control and responsibility. In my view anything like this > will be viewed > as an attempt to sneak code into the kernel that the maintainer has > already vehemently rejected. This will make people angry and > damage the > cooperative working relationship that we are trying to build. > > > but I think we can solve that just like other information that > > gets passed from user into the IB/RDMA kernel modules. > > > > > Sharing the IP 4-tuple space cooperatively with the core in > any fashion > has been nak'd. Without this cooperation, the options we've > been able to > come up with are administrative/policy based approaches. > > Any ideas you have along these lines are welcome.
I am aware of the pending nak's and certainly don't want to sneak anything by anyone. Since we all agree that user & admins won't like the current approach I'm trying to come up with alternatives. Arkady has raised some good points regarding iSCSI and I would hope a similar solution could be used for iWARP. Glenn. > > Tom > > > Glenn. > > > > > > > > - R. > > > > > _______________________________________________ > > general mailing list > > [email protected] > > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general > > > > To unsubscribe, please visit > http://openib.org/mailman/listinfo/openib-general > > _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
