Date:	Wed, 10 Jun 2015 17:43:15 +0100
From:	Stefan Hajnoczi <stefanha@...hat.com>
To:	"J. Bruce Fields" <bfields@...ldses.org>
Cc:	linux-nfs@...r.kernel.org,
	Anna Schumaker <anna.schumaker@...app.com>,
	Trond Myklebust <trond.myklebust@...marydata.com>,
	asias.hejun@...il.com, netdev@...r.kernel.org,
	Daniel Berrange <berrange@...hat.com>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [RFC 00/10] NFS: add AF_VSOCK support to NFS client

On Mon, Jun 08, 2015 at 05:02:47PM -0400, J. Bruce Fields wrote:
> On Thu, Jun 04, 2015 at 05:45:43PM +0100, Stefan Hajnoczi wrote:
> > The approach in this series
> > ---------------------------
> > AF_VSOCK stream sockets can be used for NFSv4.1 much in the same way as TCP.
> > RFC 1831 record fragments divide messages since SOCK_STREAM semantics are
> > present.  The backchannel shares the connection just like the default TCP
> > configuration.
> 
> So the NFSv4 backchannel isn't handled for now, I assume.

Right, I did not touch nfs4_callback_up_net(), only
nfs41_callback_up_net().

If I'm reading the code right NFSv4 uses a separate listen port for the
backchannel instead of sharing the client's socket?

This is possible to implement with AF_VSOCK but I have only tested
NFSv4.1 so far.  Should I go ahead and do this?

> And I guess
> NFSv2/v3 is out too thanks to rpcbind?  Which maybe is fine.

Yes, I ignored rpcbind and didn't test NFSv2/v3.

> Do we need an IETF draft or similar to document how NFS should work over
> AF_VSOCK?

I am not familiar with the standards process but I came across a few
places where it makes sense to have a standard:

 * SUNRPC netid for AF_VSOCK (currently "tcp", "udp", and others exist)
 * The uaddr string format ("vsock:...")
 * Use of RFC 1831 record fragments (just like TCP) over AF_VSOCK
   SOCK_STREAM sockets

These are all at the SUNRPC level rather than at the NFS protocol level.

Any idea who I need to talk to?

> NFS developers rely heavily on wireshark (and similar tools) for
> debugging.  Is that still possible over AF_VSOCK?

No, this will require kernel and libpcap patches.  Something like
drivers/net/nlmon.c is needed for AF_VSOCK.  Basically a dummy network
interface and code that clones skbs when monitoring is enabled.

It's on the TODO list and will be very useful.

> > The next step is tackling NFS server.  In the meantime, I have tested the
> > patches using the nc-vsock netcat-like utility that is available in my Linux
> > kernel repo below.
> 
> So by a netcat-like utility, you mean it's proxying between client and a
> server so the client thinks the server is communicating over AF_VSOCK
> and the server thinks the client is using TCP?  (Sorry, I haven't looked
> at the code.)

Yes, exactly.  It works since the TCP and AF_VSOCK streams are almost
bit-compatible.  I think the difference between the streams occurs when
network addresses are transmitted (e.g. SUNRPC netids), but I haven't
encountered that with NFSv4.1 and no pnfs or fancy features in use.

> Once we have a server and client, how will you recommend testing them?
> (Will the server side need to run on real hardware?)

I have been testing nfsd on the host and nfs client in a virtual
machine.  Vice versa should work in the same way.

It's also possible to run nfsd in VM #1 and nfs client in VM #2 and use
the netcat-like utility on the host to forward the traffic.  That way
any kernel panic happens in a VM and doesn't bring down the machine.
I'll probably begin using this approach when I start nfsd work.

> I guess if it works then the main question is whether it's worth
> supporting another transport type in order to get the zero-configuration
> host<->guest NFS setup.  Or whether there's another way to get the same
> gains.

Thanks!  If anyone has suggestions to avoid adding the AF_VSOCK
transport I'd be interested to learn about that.

Stefan

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists