qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] vhost-pci and virtio-vhost-user


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] vhost-pci and virtio-vhost-user
Date: Fri, 19 Jan 2018 17:20:49 +0000
User-agent: Mutt/1.9.1 (2017-09-22)

On Thu, Jan 18, 2018 at 07:51:49PM +0800, Jason Wang wrote:
> 
> 
> On 2018年01月18日 18:51, Stefan Hajnoczi wrote:
> > On Tue, Jan 16, 2018 at 01:41:37PM +0800, Jason Wang wrote:
> > > 
> > > On 2018年01月15日 21:56, Stefan Hajnoczi wrote:
> > > > On Mon, Jan 15, 2018 at 02:56:31PM +0800, Jason Wang wrote:
> > > > > On 2018年01月12日 18:18, Stefan Hajnoczi wrote:
> > > > > > > And what's more important, according to the kvm 2016 slides of 
> > > > > > > vhost-pci,
> > > > > > > the motivation of vhost-pci is not building SDN but a chain of 
> > > > > > > VNFs. So
> > > > > > > bypassing the central vswitch through a private VM2VM path does 
> > > > > > > make sense.
> > > > > > > (Though whether or not vhost-pci is the best choice is still 
> > > > > > > questionable).
> > > > > > This is probably my fault.  Maybe my networking terminology is 
> > > > > > wrong.  I
> > > > > > consider "virtual network functions" to be part of "software-defined
> > > > > > networking" use cases.  I'm not implying there must be a central 
> > > > > > virtual
> > > > > > switch.
> > > > > > 
> > > > > > To rephrase: vhost-pci enables exitless VM2VM communication.
> > > > > The problem is, exitless is not what vhost-pci invents, it could be 
> > > > > achieved
> > > > > now when both sides are doing busypolling.
> > > > The only way I'm aware of is ivshmem.  But ivshmem lacks a family of
> > > > standard device types that allows different implementations to
> > > > interoperate.  We already have the virtio family of device types, so it
> > > > makes sense to work on a virtio-based solution.
> > > > 
> > > > Perhaps I've missed a different approach for exitless VM2VM
> > > > communication.  Please explain how VM1 and VM2 can do exitless network
> > > > communication today?
> > > I'm not sure we're talking the same thing. For VM2VM, do you mean only for
> > > shared memory? I thought we can treat any backends that can transfer data
> > > directly between two VMs for a VM2VM solution. In this case, if virtqueue
> > > notifications were disabled by all sides (e.g busy polling), there will be
> > > no exits at all.
> > > 
> > > And if you want a virtio version of shared memory, it's another kind of
> > > motivation at least from my point of view.
> > I'm confused, we're probably not talking about the same thing.
> > 
> > You said that exitless "could be achieved now when both sides are doing
> > busypolling".  Can you post a QEMU command-line that does this?
> 
> If exitless means no virtqueue kick and interrupt. It does not require any
> special command line, just start a testpmd in both guest and host.
> 
> > 
> > In other words, what exactly are you proposing as an alternative to
> > vhost-pci?
> 
> I don't propose any new idea. I just want to know what's the advantage of
> vhost-pci over zerocopy. Both needs one time of copy, the difference is the
> vhost-pci did it inside a guest but zerocopy did in on host.

Exitless VM2VM communication is desirable if you cannot run software on
the host or if both endpoints are already in VMs.  In that case running
one thing in a VM and another on the host doesn't make sense.

The obvious environment where this applies is in the cloud where
everything is a VM.

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

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