Re: [PATCH 0/3] RDMA/core: iWARP Port Mapper Overview

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

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.

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...

> > 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.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html