From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41874) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjoLk-0000i8-Hl for qemu-devel@nongnu.org; Fri, 22 Nov 2013 05:52:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VjoLe-0004nw-SR for qemu-devel@nongnu.org; Fri, 22 Nov 2013 05:52:36 -0500 Received: from mail-we0-x232.google.com ([2a00:1450:400c:c03::232]:50218) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjoLe-0004nr-Kx for qemu-devel@nongnu.org; Fri, 22 Nov 2013 05:52:30 -0500 Received: by mail-we0-f178.google.com with SMTP id u56so952939wes.23 for ; Fri, 22 Nov 2013 02:52:29 -0800 (PST) Date: Fri, 22 Nov 2013 11:52:27 +0100 From: Stefan Hajnoczi Message-ID: <20131122105227.GC24388@stefanha-thinkpad.redhat.com> References: <20131119161144.GA1115@stefanha-thinkpad.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [RFC] Architecture to connect a userspace ethernet switch to QEMU guests via Virtio List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Antonios Motakis Cc: Luke Gorrie , Daniel Raho , qemu-devel qemu-devel , Anthony Liguori , "Michael S. Tsirkin" On Thu, Nov 21, 2013 at 12:01:20PM +0100, Antonios Motakis wrote: > On Tue, Nov 19, 2013 at 5:11 PM, Stefan Hajnoczi wrote: > > 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). > > > > Actually, our intended approach is not that different; it is still > under the control of the vapp 'client' (QEMU) what virtqueues it will > pass to the userspace process. There is nothing stopping us from doing > the same thing and handle the ctrl virtqueue in virtio_net. > > In fact, we are currently evaluating the possibility to implement vapp > not as a completely new component, but as a feature of vhost. We need > to decouple some things, however it looks like it is the cleanest > approach. This makes sense, because virito_net already knows how to > 'coordinate' with vhost. > > To do this we need to decouple ioctl calls in vhost and add support > for our (very similar) unix domain socket interface. Also, another > main difference is that we do not need to set a TAP device (we are > network backend agnostic, since we let the target process decide what > to do with network data). > > > 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. > > Point taken. It is one of our goals to have the code eventually > upstreamed., so I hope with the above clarifications, our intended > solution is deemed more acceptable. To me it sounds okay to follow a vhost-like interface. But I think that Michael Tsirkin and Anthony Liguori's thoughts would be interesting too. I've CCed them. Stefan