[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] Re: [RFC virtio-dev] vhost-user-slave: add vhost-user slave device type
On Tue, Dec 19, 2017 at 04:00:13PM +0800, Wei Wang wrote: > On 12/16/2017 01:05 AM, Stefan Hajnoczi wrote: > > The vhost-user slave device facilitates vhost-user device emulation > > through vhost-user protocol exchanges and access to shared memory. > > Software-defined networking, storage, and other I/O appliances can > > provide services through this device. > > > > This device is based on Wei Wang's vhost-pci work. The vhost-user slave > > device differs from vhost-pci because it is a single virtio device type > > that exposes the vhost-user protocol instead of a family of new virtio > > device types, one for each vhost-user device type. > > > > This device supports vhost-user slave and vhost-user master > > reconnection. It also contains a UUID so that vhost-user slave programs > > can identify a specific device among many without using bus addresses. > > > > It is somewhat unconventional for a virtio device because it makes use > > of additional resources called doorbells, notifications, and shared > > memory. A mapping of these resources to the virtio PCI transport is > > provided. Other transports, such as CCW may not be able to support > > this device. > > Hi Stefan, > > Sorry for being late. I need to shift my focus to some other things for a > week or two. No problem. I will be offline 25 Dec - 1 Jan for the winter holidays. Regardless of which approach we use in the end, the virtio PCI transport extensions for doorbell, notification, and shared memory resources defined in this RFC will be necessary. I hope you'll find that part interesting. > I still couldn't see how those problems can be solved with this slave device > proposal (which vhost-pci doesn't have): I'm not sure if we are thinking of the same design. I've answered your questions below. I'm also implementing the vhost-user-slave device to show exactly how this approach works and will share the code once it's ready. > - The complexity of the "relaying" mechanism for two directions > (GuestSlave<->QemuSlave<->Master). I couldn't think of a simple way to do > this. If you know a *simple* way, could you please describe the detailed > steps or show a picture of the details? (I think most of us couldn't see the > true advantage over the vhost-pci's method) I posted a list of vhost-user protocol messages and what action QEMU needs to take before relaying them: https://lists.gnu.org/archive/html/qemu-devel/2017-12/msg02315.html What is complex about this? How is it more complex than the vhost-pci approach? vhost-pci needs to parse everything too, plus it also needs to translate that into new virtio devices that would need to be defined for each device type (net, blk, scsi). > - Reusability. We seem to have no chance to reuse one slave implementation > for GuestSlave and QemuSlave, which also wasn't your intention as you > mentioned. If this couldn't be solved, shall we give up this option? Reusability means that vhost-user slaves can support both UNIX domain sockets and the vhost-user-slave device. For example, vhost-user-slave device support can be added to the DPDK vhost-user slave without rewriting the net device: http://dpdk.org/browse/dpdk/tree/lib/librte_vhost The same can be done in QEMU's contrib/libvhost-user. It means that a slave program can run on UNIX domain sockets or the vhost-user-slave device without significant modifications. The vhost-pci approach exposes a new virtio device that is totally different from vhost-user. Do you plan on writing a whole new driver from scratch for DPDK? Stefan
Attachment:
signature.asc
Description: PGP signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]