Re: [RFC, PATCH 33/33] knfsd: Support adding transports by writing portlist file

[Tom Tucker <tom@opengridcomputing.com>]

On Fri, 2007-09-28 at 14:48 +1000, Neil Brown wrote:
> On Thursday September 27, tom@opengridcomputing.com wrote:
> > 
> > Update the write handler for the portlist file to allow creating new
> > listening endpoints on a transport. The general form of the string is:
> > 
> > <transport_name><space><port number>
> > 
> > For example:
> > 
> > tcp 2049
> > 
> > This is intended to support the creation of a listening endpoint for
> > RDMA transports without adding #ifdef code to the nfssvc.c file.
> > The general idea is that the rpc.nfsd program would read the transports
> > file and then write the portlist file to create listening endpoints
> > for all or selected transports. The current mechanism of writing an
> > fd would become obsolete.
> 
> Nuh.
> I'll only accept
>       rdma 2049
> (or whatever) because there seems to be no other way to do it.
> Writing an 'fd' is the *preferred* way.
> 
> There is more to binding an endpoint than protocol and port number.
> There is also local address and I'm not convinced that someone might
> come up with some other way they want to pre-condition a socket.

Agreed. 

Forgive me for deferring the it-should-be-socket question for a
paragraph or two, but...

This version was much less ambitious than what I wanted to do, which was
extend the syntax and consolidate listener creation.

The string would be something like:

addr-qualifier addr port xprt-string xprt-specific-ops

For example,
ipv4 0.0.0.0 2049 udp
ipv4 10.2.1.5 2049 tcp
ipv6 ff:ff:ff:ff:10.4.1.5 2049 tcp
ipv4 10.3.1.5 2050 rdma 

The upside is that all listeners would be created in the same way. The
downside is that the string processing and endpoint creation are all
done in the kernel in the proc-fs handler.

> If there was any way to associate an RDMA endpoint with a
> filedescriptor, I would much prefer that 'rpc.nfsd' does that and passes
> down the filedescriptor.  

With regard to associating a socket with an RDMA endpoint, IMO it is
technically feasible, but politically impossible at this point. Various
degrees of integration have been discussed on both the OpenFabrics and
netdev mailing lists. To summarize the viewpoints:

- Key "netdev/core people" do not want _any_ core changes to enable RDMA
under any circumstances. They believe iWARP(RDMA/TOE) and IB (RDMA) are
"point in time technologies" that are doomed to the bone pile and that
integrating into the core would complicate and destabilize the stack.

- Most "RDMA people" see no benefit in sockets because the I/O model is
so different, the sockets connection model is not asynchronous, and
there is no way to specify the RDMA transport connection and route
qualifiers.

- A few "RDMA people" like a sockets approach. It was actually
implemented as part of an early SDP IB implementation. 

Obviously, there are as many variants of the above as there are dogs in
the fight, but this is my sense of the fundamental issues.

> If RDMA is so no-Unix-like (rant rant..) 
> that there is no such file descriptor, then I guess we can live with 
> getting the kernel to open the connection.
> 

At this point, I believe this is the way to do it. 

Thanks,

Tom
> 
> > 
> > Signed-off-by: Tom Tucker <tom@opengridcomputing.com>
> > ---
> > 
> >  fs/nfsd/nfsctl.c |   16 ++++++++++++++++
> >  1 files changed, 16 insertions(+), 0 deletions(-)
> > 
> > diff --git a/fs/nfsd/nfsctl.c b/fs/nfsd/nfsctl.c
> > index baac89d..923b817 100644
> > --- a/fs/nfsd/nfsctl.c
> > +++ b/fs/nfsd/nfsctl.c
> > @@ -554,6 +554,22 @@ static ssize_t write_ports(struct file *
> >  		kfree(toclose);
> >  		return len;
> >  	}
> > +	/*
> > +	 * Add a transport listener by writing it's transport name
> > +	 */
> > +	if (isalnum(buf[0])) {
> 
> Should really be "isalpha" as we already know it isn't isdigit.
> 
> NeilBrown
> 
> 
> > +		int err;
> > +		char transport[16];
> > +		int port;
> > +		if (sscanf(buf, "%15s %4d", transport, &port) == 2) {
> > +			err = nfsd_create_serv();
> > +			if (!err)
> > +				err = svc_create_xprt(nfsd_serv,
> > +						      transport, port,
> > +						      SVC_SOCK_ANONYMOUS);
> > +			return err < 0 ? err : 0;
> > +		}
> > +	}
> >  	return -EINVAL;
> >  }
> >  


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs