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

[Greg Banks <gnb@sgi.com>]

On Fri, Sep 28, 2007 at 02:48:56PM +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.
> 
> If there was any way to associate an RDMA endpoint with a
> filedescriptor,

The whole point of RDMA is not to have a file descriptor or any of that
slow stuff like read(), write(), or reliable connections in software.
(Of course you also lose helpful things like strace, tethereal, and
iptables.  Swings...roundabouts.)

In the case of the local address, you could pass that into the
portlist file too, like:

echo 'tcp 192.168.0.1:2049' > /proc/fs/nfsd/portlist

Or perhaps

echo '23/rdma' > /proc/fs/nfsd/portlist

where 23 is the same file descriptor passed for TCP?


> I would much prefer that 'rpc.nfsd' does that and passes
> down the filedescriptor.  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.

It's as unUnixlike as you can imagine :-/

Greg.
-- 
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
Apparently, I'm Bedevere.  Which MPHG character are you?
I don't speak for SGI.

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