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@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-821-5101 fax. 734-769-8938 cel. 734-216-5309 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
