> -----Original Message----- > From: linux-rdma-ow...@vger.kernel.org > [mailto:linux-rdma-ow...@vger.kernel.org] On Behalf Of Jason Gunthorpe > Sent: Monday, June 09, 2014 1:42 PM > To: Steve Wise > Cc: 'Or Gerlitz'; Nikolova, Tatyana E; 'Roland Dreier'; Lacombe, John S; > Hefty, Sean; 'linux-rdma' > Subject: Re: [PATCH 0/3] RDMA/core: iWARP Port Mapper Overview > > On Mon, Jun 09, 2014 at 01:12:50PM -0500, Steve Wise wrote: > > > > > 1. kernel rdma driver tells a user space daemon they want to > > > > reserve > > > > (claim) the combination of IP address X and TCP port Y for the > > > > sake of RDMA connections > > > > > > > > 2. user space daemon opens a socket and binds to X:Y > > > > > > > > Specifically, down the road, more use cases, not only the current > > > > iWARP case may pop up. > > > > > > This really seems horrible, using user space to circumvent the > > > kernel stack because kernel maintainers don't want this kind of > > > integration is not going to make people very happy. > > > > > > IIRC the patch set that tried to do this directly in the kernel was > > > NAK'd, adding a userspace round trip doesn't really change anything. > > > The patch set you refer to tried to _unify_ the port space and was > > rejected. The only other alternative is to pick ephemeral ports and > > maintain a mapping for RDMA services. > > I thought both approaches were tried in kernel and NAK'd by netdev? > This looks very similar to the 2010 patchset, except the dummy socket > allocation is living in userspace in this version.
This was something I presented and discussed at NetConf 2011 with David and other netdev core folks: http://vger.kernel.org/netconf2011.html. The main issue David had with the original approach was the socket was being consumed by something else inside the kernel. It circumvented the TCP socket allocation/reservation code, which was frowned upon. The compromise we came up with is the approach in this patchset. As long as the socket is claimed via userspace, David had no problem with the approach. > Again, from here, this looks like another patch to do an end-run around > netdev's NAK by hiding the offending stuff in userspace. That is no good > either... See above. > > > The message from netdev has, IMHO, always been pretty clear - > > > offload can live in it's own little side world but cannot appear to > > > the user to be integrated to the main stack (because it isn't). > > > > That is what this design does... > > Not really, it is still sharing an IP used by the main stack, otherwise you > wouldn't have this problem in the first place. The reason we didn't back down from having separate IP's is because there are customers using iWARP that want the traffic converged, using a single IP. This approach is the best way we came up with as a group, it just took a bit of time to get headcount onto it and developed/tested. Cheers, -PJ -- 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
