[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH/RFC 0/1] Vhost User Cross Cable: Intro

From: Nikos Dragazis
Subject: Re: [PATCH/RFC 0/1] Vhost User Cross Cable: Intro
Date: Thu, 13 Feb 2020 15:48:59 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

On Tue, 14 Jan 2020 at 10:20 Stefan Hajnoczi
<address@hidden> wrote:
> On Fri, Jan 10, 2020 at 10:34 AM Marc-André Lureau
> <address@hidden> wrote:
> > On Wed, Jan 8, 2020 at 5:57 AM V. <address@hidden> wrote:
> Hi V.,
> I think I remember you from Etherboot/gPXE days :).
> > > 3.
> > > Now if Cross Cable is actually a new and (after a code-rewrite of 10) a
> > > viable way to connect 2 QEMU's together, could I actually
> > > suggest a better way?
> > > I am thinking of a '-netdev vhost-user-slave' option to connect (as client
> > > or server) to a master QEMU running '-netdev vhost-user'.
> > > This way there is no need for any external program at all, the master can
> > > have it's memory unshared and everything would just work
> > > and be fast.
> > > Also the whole thing can fall back to normal virtio if memory is not 
> > > and it would even work in pure usermode without any
> > > context switch.
> > >
> > > Building a patch for this idea I could maybe get around to, don't clearly
> > > have an idea how much work this would be but I've done
> > > crazier things.
> > > But is this is something that someone might be able to whip up in an hour
> > > or two? Someone who actually does have a clue about vhost
> > > and virtio maybe? ;-)
> >
> > I believe https://wiki.qemu.org/Features/VirtioVhostUser is what you
> > are after. It's still being discussed and non-trivial, but not very
> > active lately afaik.
> virtio-vhost-user is being experimented with in the SPDK community but
> there has been no activity on VIRTIO standardization or the QEMU
> patches for some time.  More info here:
> https://ndragazis.github.io/spdk.html
> I think the new ivshmem v2 feature may provide the functionality you
> are looking for, but I haven't looked at them yet.  Here is the link:
> https://www.mail-archive.com/address@hidden/msg668749.html
> And here is Jan's KVM Forum presentation on ivshmem v2:
> https://www.youtube.com/watch?v=TiZrngLUFMA
> Stefan

Hi Stefan,

First of all, sorry for the delayed response. The mail got lost
somewhere in my inbox. Please keep Cc-ing me on all threads related to

As you correctly pointed out, I have been experimenting with
virtio-vhost-user on SPDK and [1] is a working demo on this matter. I
have been working on getting it merged with SPDK and, to this end, I
have been interacting with the SPDK team [2][3] and mostly with Darek
Stojaczyk (Cc-ing him).

The reason that you haven’t seen any activity for the last months is
that I got a job and hence my schedule has become tighter. But I will
definitely find some space and fit it into my schedule. Let me give you
a heads up, so that we get synced:

Originally, I created and sent a patch (influenced from your DPDK patch
[4]) to SPDK that was enhancing SPDK’s internal rte_vhost library with
the virtio-vhost-user transport. However, a few weeks later, the SPDK
team decided to switch from their internal rte_vhost library to using
DPDK’s rte_vhost library directly [3]. Given that, I refactored and sent
the patch for the virtio-vhost-user transport to the DPDK mailing list
[5]. Regarding the virtio-vhost-user device, I have made some
enhancements [6] on your original RFC device implementation and, as you
may remember, I have sent some revised versions of the spec to the
virtio mailing list [7].

At the moment, the blocker is the virtio spec. The last update on this
was my discussion with Michael Tsirkin (Cc-ing him as well) about the
VIRTIO_PCI_CAP_NOTIFICATION_CFG configuration structures [8].

So, I think the next steps should be the following:

1. merging the spec
2. adding the device on QEMU
3. adding the vvu transport on DPDK
4. extending SPDK to make use of the new vhost-user transport

To conclude, I still believe that this device is useful and should be
part of virtio/qemu/dpdk/spdk and I will continue working on this

Best regards,

[1] https://ndragazis.github.io/spdk.html
[4] http://mails.dpdk.org/archives/dev/2018-January/088155.html
[5] https://lore.kernel.org/dpdk-dev/address@hidden/T/
[6] https://lists.gnu.org/archive/html/qemu-devel/2019-04/msg02910.html
[7] https://lists.oasis-open.org/archives/virtio-dev/201906/msg00036.html
[8] https://lists.oasis-open.org/archives/virtio-dev/201908/msg00014.html

reply via email to

[Prev in Thread] Current Thread [Next in Thread]