On Fri, Jan 12, 2018 at 02:44:00PM +0800, Wei Wang wrote: > On 01/11/2018 05:56 PM, Stefan Hajnoczi wrote: > > On Thu, Jan 11, 2018 at 6:31 AM, Wei Wang <wei.w.w...@intel.com> wrote: > > > On 01/11/2018 12:14 AM, Stefan Hajnoczi wrote: > > > Without above two, the solution already works well, so I'm not sure why > > > would we need the above two from functionality point of view. > > The "[PATCH v3 0/7] Vhost-pci for inter-VM communication" series is > > incomplete. It is a subset of vhost-user-net and it works only for > > poll-mode drivers. It's the requirements that haven't been covered by > > the vhost-pci patch series yet that make me prefer the > > virtio-vhost-user approach. > > > > The virtio device design needs to be capable of supporting the rest of > > vhost-user functionality in the future. Once the code is merged in > > QEMU and DPDK it will be very difficult to make changes to the virtio > > device. > > This is how virtio works. A new feature with a new feature bit.
Although it is possible to add a feature bit that radically changes the virtio device's interface, the existing driver software would need to be largely rewritten - all the way up to the net, scsi, blk, etc devices. We cannot easily migrate between the vhost-pci to virtio-vhost-user approaches later. > Now, we let > the guest driver join the vhost-user negotiation (including feature > negotiation), the default device/driver feature negotiation is free to use. > I'm thinking if it is worthwhile to do some kind of mediated passthrough, > which passes the selected messages only. Because many messages are not > necessary to be passed down (e.g. VHOST_USER_SEND_RARP is not needed for > simple VM-to-VM communication), though might be safe to do. I plan to see > your full passthrough code first, and see if changing to mediated > passthrough would be simpler. I expect vhost-pci to require fewer code changes. If you judge "simpler" just by the patch count or size, then vhost-pci will win. The reason for that is virtio-vhost-user integrates with librte_vhost. This requires refactoring librte_vhost to support multiple transports. I think the virtio-vhost-user end result is worth it though: vhost devices like examples/vhost/ and examples/vhost/scsi/ will work with both AF_UNIX and virtio-vhost-user. This makes it simpler for users and vhost device developers - you only have one implementation of net, scsi, blk, etc devices. Stefan
signature.asc
Description: PGP signature
