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: 15+ 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 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 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
[not found] ` <1433436353-6761-1-git-send-email-stefanha-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-04 16:45 ` [RFC 01/10] SUNRPC: add AF_VSOCK support to addr.h 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 ` [RFC 07/10] SUNRPC: restrict backchannel svc IPPROTO_TCP check to IP Stefan Hajnoczi
2015-06-08 21:02 ` [RFC 00/10] NFS: add AF_VSOCK support to NFS client J. Bruce Fields
[not found] ` <20150608210247.GB27887-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
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$(echo .)org \
--cc=anna.schumaker@netapp$(echo .)com \
--cc=asias.hejun@gmail$(echo .)com \
--cc=berrange@redhat$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=linux-nfs@vger$(echo .)kernel.org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=stefanha@redhat$(echo .)com \
--cc=trond.myklebust@primarydata$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox