From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34740) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UgXJu-0002fr-QL for qemu-devel@nongnu.org; Sun, 26 May 2013 05:32:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UgXJq-0000NI-U8 for qemu-devel@nongnu.org; Sun, 26 May 2013 05:32:54 -0400 Received: from mail-bk0-x22e.google.com ([2a00:1450:4008:c01::22e]:48066) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UgXJq-0000Ko-Kh for qemu-devel@nongnu.org; Sun, 26 May 2013 05:32:50 -0400 Received: by mail-bk0-f46.google.com with SMTP id my13so3193528bkb.5 for ; Sun, 26 May 2013 02:32:49 -0700 (PDT) MIME-Version: 1.0 Date: Sun, 26 May 2013 11:32:49 +0200 Message-ID: From: Luke Gorrie Content-Type: multipart/alternative; boundary=001a11c3737826c38504dd9bb76f Subject: [Qemu-devel] snabbswitch integration with QEMU for userspace ethernet I/O List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: "snabb-devel@googlegroups.com" , stefanha@redhat.com, mst@redhat.com --001a11c3737826c38504dd9bb76f Content-Type: text/plain; charset=ISO-8859-1 Dear qemu-devel hackers, I am writing to ask for some technical advice. I am making embarrassingly slow progress on finding a good way to integrate the Snabb Switch user-space ethernet switch (http://snabb.co/snabbswitch/) with QEMU for efficient ethernet I/O. Stefan put us onto the highly promising track of vhost/virtio. We have implemented this between Snabb Switch and the Linux kernel, but not directly between Snabb Switch and QEMU guests. The "roadblock" we have hit is embarrasingly basic: QEMU is using user-to-kernel system calls to setup vhost (open /dev/net/tun and /dev/vhost-net, ioctl()s) and I haven't found a good way to map these towards Snabb Switch instead of the kernel. We have several ideas on the table and we would love some technical feedback on what sounds like a good way forward -- ideally a better alternative that we haven't thought of at all, not being QEMU gurus ourselves. Here are the ideas on the table right now: 1. Use FUSE to implement a complete clone of /dev/net/tun and /dev/vhost-net inside Snabb Switch. Implement every ioctl() that QEMU requires. 2. Extend QEMU to support a user-user IPC mode of vhost. In this mode QEMU would not use ioctl() etc but some other system calls that are appropriate for IPC between user-space processes. 3. Use the kernel as a middle-man. Create a double-ended "veth" interface and have Snabb Switch and QEMU each open a PF_PACKET socket and accelerate it with VHOST_NET. #1 is appealing _if_ it can really be done. Risk is that we hit a road-block when implementing the behavior of the ioctl()s, for example have trouble mapping guest memory or getting hold of an eventfd, and that FUSE is kinda heavy-weight. #2 is appealing _if_ it can be done in a nice way. I don't know which system calls would be appropriate and I don't know how to write the code inside QEMU in a neat way. #3 is appealing _if_ there is no significant overhead e.g. an extra memory copy inside the kernel, or if it's really quick to do as a temporary stop-gap. We would love some words of wisdom about the options above and/or a new idea :-) Cheers, -Luke --001a11c3737826c38504dd9bb76f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear qemu-devel hackers,

I am writing to ask for some technical advice. I am making embarrassingl= y slow progress on finding a good way to integrate the Snabb Switch user-sp= ace ethernet switch (http://snabb.co/snabbswitch/) with QEMU for efficient ethernet I/O= .

Stefan put us onto the highly promising track of vhost/= virtio. We have implemented this between Snabb Switch and the Linux kernel,= but not directly between Snabb Switch and QEMU guests. The "roadblock= " we have hit is embarrasingly basic: QEMU is using user-to-kernel sys= tem calls to setup vhost (open /dev/net/tun and /dev/vhost-net, ioctl()s) a= nd I haven't found a good way to map these towards Snabb Switch instead= of the kernel.

We have several ideas on the table and we would love so= me technical feedback on what sounds like a good way forward -- ideally a b= etter alternative that we haven't thought of at all, not being QEMU gur= us ourselves.

Here are the ideas on the table right now:
1. Use FUSE to implement a complete clone of /dev/net/tun and = /dev/vhost-net inside Snabb Switch. Implement every ioctl() that QEMU requi= res.

2. Extend QEMU to support a user-user IPC mode of vhost= . In this mode QEMU would not use ioctl() etc but some other system calls t= hat are appropriate for IPC between user-space processes.

3. Use the kernel as a middle-man. Create a double-ended "v= eth" interface and have Snabb Switch and QEMU each open a PF_PACKET so= cket and accelerate it with VHOST_NET.

#1 is appea= ling _if_ it can really be done. Risk is that we hit a road-block when impl= ementing the behavior of the ioctl()s, for example have trouble mapping gue= st memory or getting hold of an eventfd, and that FUSE is kinda heavy-weigh= t.

#2 is appealing _if_ it can be done in a nice way. I do= n't know which system calls would be appropriate and I don't know h= ow to write the code inside QEMU in a neat way.

#3 is appealing _if_ there is no significant overhead e.g. an extra memory = copy inside the kernel, or if it's really quick to do as a temporary st= op-gap.

We would love some words of wisdom about t= he options above and/or a new idea :-)

Cheers,
-Luke

--001a11c3737826c38504dd9bb76f--