From: "J. Bruce Fields" <bfields@fieldses.org>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: linux-nfs@vger.kernel.org,
Anna Schumaker <anna.schumaker@netapp.com>,
Trond Myklebust <trond.myklebust@primarydata.com>,
asias.hejun@gmail.com, netdev@vger.kernel.org,
Daniel Berrange <berrange@redhat.com>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [RFC 00/10] NFS: add AF_VSOCK support to NFS client
Date: Wed, 10 Jun 2015 14:09:26 -0400 [thread overview]
Message-ID: <20150610180926.GC8922@fieldses.org> (raw)
In-Reply-To: <20150610164315.GD17294@stefanha-thinkpad.redhat.com>
On Wed, Jun 10, 2015 at 05:43:15PM +0100, Stefan Hajnoczi wrote:
> 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?
Right.
> This is possible to implement with AF_VSOCK but I have only tested
> NFSv4.1 so far. Should I go ahead and do this?
Personally I'd make it a lower priority--I don't see why you can't make
4.1 a requirement for the new transport--but I'd be curious what others
have to say.
> > 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:...")
Off the top of my head I can't remember where else that's used in the
protocol other than in setting up the 4.0 callback connection (and in
rpcbind).
> * Use of RFC 1831 record fragments (just like TCP) over AF_VSOCK
> SOCK_STREAM sockets
As far as I can tell, 1831 claims to be independent of any transport
protocol details: "The RPC protocol can be implemented on several
different transport protocols. The RPC protocol does not care how a
message is passed from one process to another, but only with
specification and interpretation of messages." And: "When RPC messages
are passed on top of a byte stream transport protocol (like TCP)"....
So perhaps there's nothing more to say here.
> These are all at the SUNRPC level rather than at the NFS protocol level.
>
> Any idea who I need to talk to?
Anyay, if there is anything to be worked out, nfsv4@ietf.org is the
place to go.
--b.
next prev parent reply other threads:[~2015-06-10 18:09 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-04 16:45 [RFC 00/10] NFS: add AF_VSOCK support to NFS client Stefan Hajnoczi
2015-06-04 16:45 ` [RFC 01/10] SUNRPC: add AF_VSOCK support to addr.h Stefan Hajnoczi
2015-06-04 16:45 ` Stefan Hajnoczi
2015-06-04 16:45 ` [RFC 02/10] SUNRPC: rename "TCP" record parser to "stream" parser Stefan Hajnoczi
2015-06-04 16:45 ` Stefan Hajnoczi
2015-06-04 16:45 ` [RFC 03/10] SUNRPC: abstract tcp_read_sock() in record fragment parser Stefan Hajnoczi
2015-06-04 16:45 ` [RFC 04/10] SUNRPC: extract xs_stream_reset_state() Stefan Hajnoczi
2015-06-04 16:45 ` [RFC 05/10] VSOCK: add tcp_read_sock()-like vsock_read_sock() function Stefan Hajnoczi
2015-06-04 16:45 ` [RFC 06/10] SUNRPC: add AF_VSOCK support to xprtsock.c Stefan Hajnoczi
2015-06-04 16:45 ` [RFC 07/10] SUNRPC: restrict backchannel svc IPPROTO_TCP check to IP Stefan Hajnoczi
2015-06-04 16:45 ` Stefan Hajnoczi
2015-06-04 16:45 ` [RFC 08/10] SUNRPC: add vsock-bc backchannel Stefan Hajnoczi
2015-06-04 16:45 ` [RFC 09/10] SUNRPC: add AF_VSOCK support to svc_xprt.c Stefan Hajnoczi
2015-06-04 16:45 ` [RFC 10/10] NFS: add AF_VSOCK support to NFS client Stefan Hajnoczi
2015-06-08 21:02 ` [RFC 00/10] " J. Bruce Fields
2015-06-08 21:02 ` J. Bruce Fields
2015-06-10 16:43 ` Stefan Hajnoczi
2015-06-10 16:43 ` Stefan Hajnoczi
2015-06-10 18:09 ` J. Bruce Fields [this message]
2015-06-11 9:19 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150610180926.GC8922@fieldses.org \
--to=bfields@fieldses.org \
--cc=anna.schumaker@netapp.com \
--cc=asias.hejun@gmail.com \
--cc=berrange@redhat.com \
--cc=davem@davemloft.net \
--cc=linux-nfs@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=stefanha@redhat.com \
--cc=trond.myklebust@primarydata.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.