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
Attachment:
pgp4cf28SRpLa.pgp
Description: PGP signature
