From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49653) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eZaXx-0002OW-4L for qemu-devel@nongnu.org; Thu, 11 Jan 2018 05:57:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eZaXs-0001Pd-6j for qemu-devel@nongnu.org; Thu, 11 Jan 2018 05:57:21 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54558) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eZaXr-0001P0-Ts for qemu-devel@nongnu.org; Thu, 11 Jan 2018 05:57:16 -0500 References: <20180110161438.GA28096@stefanha-x1.localdomain> From: Jason Wang Message-ID: Date: Thu, 11 Jan 2018 18:57:03 +0800 MIME-Version: 1.0 In-Reply-To: <20180110161438.GA28096@stefanha-x1.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] vhost-pci and virtio-vhost-user List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi , wei.w.wang@intel.com Cc: qemu-devel@nongnu.org On 2018=E5=B9=B401=E6=9C=8811=E6=97=A5 00:14, Stefan Hajnoczi wrote: > Hi Wei, > I wanted to summarize the differences between the vhost-pci and > virtio-vhost-user approaches because previous discussions may have been > confusing. > > vhost-pci defines a new virtio device type for each vhost device type > (net, scsi, blk). It therefore requires a virtio device driver for eac= h > device type inside the slave VM. > > Adding a new device type requires: > 1. Defining a new virtio device type in the VIRTIO specification. > 3. Implementing a new QEMU device model. > 2. Implementing a new virtio driver. > > virtio-vhost-user is a single virtio device that acts as a vhost-user > protocol transport for any vhost device type. It requires one virtio > driver inside the slave VM and device types are implemented using > existing vhost-user slave libraries (librte_vhost in DPDK and > libvhost-user in QEMU). > > Adding a new device type to virtio-vhost-user involves: > 1. Adding any new vhost-user protocol messages to the QEMU > virtio-vhost-user device model. > 2. Adding any new vhost-user protocol messages to the vhost-user slave > library. > 3. Implementing the new device slave. > > The simplest case is when no new vhost-user protocol messages are > required for the new device. Then all that's needed for > virtio-vhost-user is a device slave implementation (#3). That slave > implementation will also work with AF_UNIX because the vhost-user slave > library hides the transport (AF_UNIX vs virtio-vhost-user). Even > better, if another person has already implemented that device slave to > use with AF_UNIX then no new code is needed for virtio-vhost-user > support at all! > > If you compare this to vhost-pci, it would be necessary to design a new > virtio device, implement it in QEMU, and implement the virtio driver. > Much of virtio driver is more or less the same thing as the vhost-user > device slave but it cannot be reused because the vhost-user protocol > isn't being used by the virtio device. The result is a lot of > duplication in DPDK and other codebases that implement vhost-user > slaves. > > The way that vhost-pci is designed means that anyone wishing to support > a new device type has to become a virtio device designer. They need to > map vhost-user protocol concepts to a new virtio device type. This wil= l > be time-consuming for everyone involved (e.g. the developer, the VIRTIO > community, etc). > > The virtio-vhost-user approach stays at the vhost-user protocol level a= s > much as possible. This way there are fewer concepts that need to be > mapped by people adding new device types. As a result, it will allow > virtio-vhost-user to keep up with AF_UNIX vhost-user and grow because > it's easier to work with. > > What do you think? > > Stefan So a question is what's the motivation here? Form what I'm understanding, vhost-pci tries to build a scalable V2V=20 private datapath. But according to what you describe here,=20 virito-vhost-user tries to make it possible to implement the device=20 inside another VM. I understand the goal of vhost-pci could be done on=20 top, but it looks to me it would then rather similar to the design of=20 Xen driver domain. So I can not figure out how it can be done in a high=20 performance way. Thanks