[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] Architecture to connect a userspace ethernet swit
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [RFC] Architecture to connect a userspace ethernet switch to QEMU guests via Virtio |
Date: |
Tue, 19 Nov 2013 17:11:44 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Tue, Nov 19, 2013 at 11:17:40AM +0100, Antonios Motakis wrote:
> There have been discussions before on these lists on the topic of
> connecting a QEMU guest running a virtio_net driver, with an external
> userspace ethernet switch (Snabbswitch in particular). The essential
> requirement in this is to put the virtio backend in the external
> userspace process.
>
> The preferred direction should be similar to vhost, with the main
> difference of the control mechanism being a unix domain socket instead
> of an ioctl interface, and of course placing the backend in an
> userspace process instead the kernel.
>
> Since we are pursuing this direction,we would like to share a more
> detailed description of the architecture we are working on. Any
> feedback is most welcome. It is available here:
> http://www.virtualopensystems.com/media/snabbswitch/rfc_snabbswitch_qemu.pdf
It sounds like you are proposing an interprocess virtio device
interface. QEMU's virtio-pci emulation calls into a new vapp virtio
device inside QEMU, which then forwards virtio device calls to the vapp
process.
This is pretty different from vhost. vhost only puts rx/tx handling in
the kernel. Other functionality is handled by plain old QEMU virtio
device emulation (e.g. virtio-net ctrl virtqueue).
In the past device plugin interfaces have been rejected by the community
because they can lead to lower code quality (out-of-tree devices) and an
avenue to bypass the software license.
So what's the alternative? Reuse as much of the vhost approach as
possible and define a userspace network I/O interface instead of a
device plugin interface.
Stefan