Re: [PATCH, resend 4/4] IB/srp: Add RDMA/CM support

[Bart Van Assche <Bart.VanAssche-Sjgp3cTcYWE@public.gmane.org>]

On Fri, 2018-01-05 at 10:34 -0700, Jason Gunthorpe wrote:
> On Fri, Jan 05, 2018 at 12:21:10PM -0500, Doug Ledford wrote:
> 
> > > +static int srp_parse_in(struct sockaddr_storage *sa, const char *addr_port_str)
> > > +{
> > > +	char *addr = kstrdup(addr_port_str, GFP_KERNEL);
> > > +	char *port_str = addr;
> > > +	int ret;
> > > +
> > > +	if (!addr)
> > > +		return -ENOMEM;
> > > +	strsep(&port_str, ":");
> > > +	ret = inet_pton_with_scope(&init_net, AF_UNSPEC, addr, port_str, sa);
> > > +	kfree(addr);
> > > +	return ret;
> > > +}
> > > +
> > 
> > This particular function is problematic in that it adds new namespace
> > unaware code.  The namespace code in the RDMA stack is in a limbo state
> > of partially implemented, partially not.  I'm loathe to add any more
> > code that is not fully namespace aware as that just worsens the
> > hysteresis in the stack.  So we need to figure out how to do this in a
> > namespace aware manner.  I haven't previously been thinking about this
> > specific namespace issue, so I'm not prepared to even make suggestions
> > for a fix for this yet...
> 
> Do the userspace daemon's still manage the connection to SRP?

srp_daemon uses management datagrams to discover SRP targets and these MADs
discover the GID of the target port instead of the IP address. So I have not
even tried to add RDMA/CM support to srp_daemon. If automatic login would be
implemented for SRP and RDMA/CM I think we should define a new discovery
mechanism based on the Internet Protocol.

> If yes, then the networking information should be relative to the
> namespace of the thing that wrote to the sysfs file..

Login occurs by writing into a sysfs file created by the SRP initiator. How
about using the networking namespace of the process that writes into that
sysfs file?

> Also, are there srp_daemon patches for this too? I've been asking to
> see the userspace side for new uAPI features before accepting the
> kernel part so that everything can be well understood. If yes, please
> send, even if it is RFCish..

As explained above there are no corresponding srp_daemon patches. But it may
be interesting to have a look at the srp-test source code since I used that
software to test RDMA/CM support. See also https://github.com/bvanassche/srp-test.

Bart.