All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@redhat.com>
To: Matt Benjamin <mbenjami@redhat.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	"J . Bruce Fields" <bfields@fieldses.org>,
	Chuck Lever <chuck.lever@oracle.com>,
	Steve Dickson <steved@redhat.com>,
	Anna Schumaker <Anna.Schumaker@netapp.com>,
	Trond Myklebust <trondmy@primarydata.com>,
	Daniel Berrange <berrange@redhat.com>, NFSv4 <nfsv4@ietf.org>
Subject: Re: Draft RFC for ONC RPC over AF_VSOCK
Date: Fri, 27 Oct 2017 13:59:28 -0400	[thread overview]
Message-ID: <1509127168.4946.14.camel@redhat.com> (raw)
In-Reply-To: <CAKOnarmotB2CXdiNvnYV1Jz+0JwwA8tgQjFN1Ssy5jN95T-rsw@mail.gmail.com>

I agree -- that could be useful later. Given that, maybe we should call
the netids something like:

    vsockc: connected vsock
    vsockd: datagram vsock

AIUI, netids are just something we inherited from Sun when we got the
TI-RPC library. I don't think they are governed by any sort of
names+numbers authority, are they?

If not then we're probably define it to whatever we wish, though it
might be a good idea to talk to the Solaris folks and see if they have
any input as to the naming.

-- Jeff

On Fri, 2017-10-27 at 09:27 -0400, Matt Benjamin wrote:
> Hi Jeff,
> 
> This doc says they are:
> https://vmsplice.net/~stefan/stefanha-kvm-forum-2015.pdf
> 
> But only stream sockets are mentioned here:
> https://wiki.qemu.org/Features/VirtioVsock
> 
> Trond and Chuck suggested in an offline conversation a few weeks ago
> that they could imagine a datagram version of the transport being
> useful.  It's probably worth passing that alone.
> 
> Matt
> 
> On Fri, Oct 27, 2017 at 9:16 AM, Jeff Layton <jlayton@redhat.com> wrote:
> > On Thu, 2017-10-05 at 16:50 -0400, Matt Benjamin wrote:
> > > Hi Stefan,
> > > 
> > > On Thu, Oct 5, 2017 at 4:08 PM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
> > > > I have previously submitted patches that implement NFS client and nfsd
> > > > support for the AF_VSOCK address family.  In order for this to be
> > > > acceptable for merge the AF_VSOCK transport needs to be defined in an
> > > > IETF RFC.  Below is a draft RFC that defines ONC RPC over AF_VSOCK.
> > > > 
> > > > My patches use netid "vsock" but "tcpv" has also been suggested.  This draft
> > > > RFC still uses "vsock" but I'll update it to "tcpv" if there is consensus.
> > > > 
> > > 
> > > I think "vsock" is the appropriate netid, not "tcpv."  Stream
> > > orientation, if anything, is the general category containing TCP and
> > > VSOCK, not the reverse.  But really I think it's just more clear.
> > > 
> > 
> > Agreed. VSOCK is its own thing. It bears some resemblance to TCP, but
> > calling it tcpv would be confusing. IIRC, Chuck only proposed that when
> > we were discussing an alternative transport that would look more like a
> > typical network.
> > 
> > BTW: Does VSOCK have a connectionless mode, analogous to UDP? If so,
> > then it may be nice to consider what the netid for that might look like
> > as well, before we settle on any names.
> > --
> > Jeff Layton <jlayton@redhat.com>
> 
> 
> 

-- 
Jeff Layton <jlayton@redhat.com>

  parent reply	other threads:[~2017-10-27 17:59 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-05 20:08 Draft RFC for ONC RPC over AF_VSOCK Stefan Hajnoczi
2017-10-05 20:50 ` Matt Benjamin
2017-10-12 12:08   ` Stefan Hajnoczi
2017-10-12 16:40     ` [nfsv4] " Chuck Lever
2017-10-13 10:10       ` Stefan Hajnoczi
2017-10-27 13:16   ` Jeff Layton
2017-10-27 13:23     ` Daniel P. Berrange
2017-11-07 11:32       ` Stefan Hajnoczi
2017-10-27 13:27     ` Matt Benjamin
2017-10-27 13:29       ` Matt Benjamin
2017-10-27 17:59       ` Jeff Layton [this message]
2017-10-27 18:06         ` Chuck Lever
2017-10-05 20:53 ` Chuck Lever
2017-10-12 12:17   ` Stefan Hajnoczi
2017-10-13 14:13     ` Chuck Lever
2017-10-18 15:20       ` 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=1509127168.4946.14.camel@redhat.com \
    --to=jlayton@redhat.com \
    --cc=Anna.Schumaker@netapp.com \
    --cc=berrange@redhat.com \
    --cc=bfields@fieldses.org \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=mbenjami@redhat.com \
    --cc=nfsv4@ietf.org \
    --cc=stefanha@redhat.com \
    --cc=steved@redhat.com \
    --cc=trondmy@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.