From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MRCP4-0005AU-Ao for qemu-devel@nongnu.org; Wed, 15 Jul 2009 17:52:42 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MRCOz-00054l-MM for qemu-devel@nongnu.org; Wed, 15 Jul 2009 17:52:41 -0400 Received: from [199.232.76.173] (port=49139 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MRCOz-00054W-Ca for qemu-devel@nongnu.org; Wed, 15 Jul 2009 17:52:37 -0400 Received: from mail2.shareable.org ([80.68.89.115]:60483) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MRCOy-0005L8-NQ for qemu-devel@nongnu.org; Wed, 15 Jul 2009 17:52:37 -0400 Date: Wed, 15 Jul 2009 22:52:33 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] net: add raw backend Message-ID: <20090715215233.GO3056@shareable.org> References: <20090701162115.GA4555@shareable.org> <4A4CA747.1050509@Voltaire.com> <20090703023911.GD938@shareable.org> <4A534EC4.5030209@voltaire.com> <20090707145739.GB14392@shareable.org> <4A54B0F1.3070201@voltaire.com> <20090715203806.GF3056@shareable.org> <4A5E44CD.70209@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A5E44CD.70209@web.de> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Or Gerlitz , Herbert Xu , qemu-devel@nongnu.org Jan Kiszka wrote: > > But are you sure it's faster? > > I'd want to see measurements before I believe it. > > > > If you need any host<->VM networking, most of the time the packet > > socket isn't an option at all. Not many switches will 'U turn' > > packets as you suggest. > > FWIW, the fastest local VM<->VM bridge I've happened to measure so far > was using qemu's -net socket,listen/connect, ie. a plain local IP or > unix domain socket between two qemu instances. No tap devices, no > in-kernel bridges involved. That's not surprising, but good to know. Packet sockets aren't much use for VM<->VM bridges either ;-) However on a positive note, if packet sockets give good performance for VM<->external, and a unix domain socket gives good performance for VM<->VM, maybe a packet socket on _lo_ (the loopback interface) can be used for VM<->host communication? Then with the right (ugly) hackery in QEMU, it could query the host's MAC addresses as well as other VMs on the same host, listen on all three types of interface, and send to the appropriate one depending on destination MAC address of each packet. That might give great performance in all cases and solve the bridge configuration problem at the same time, so that you can run VMs easily which Just Work(tm) on the host's network. Then again it might not. Code would be a bit complicated, it would interact with Linux iptables differently, and one of the most useful configurations which is VMs being NAT'd by the host (so invisible outside the host) would be difficult. > But this picture may change once we have some in-kernel virtio-net > backend. If there's a faster way to send/receive packets, especially if it _behaves_ differently from tap/packet, it would be nice if it were available from userspace too, not just from KVM. If virtio-net is growing a backend to send/receive packets via the host network stack, it would be nice if it solve the awkward bridge configuration problem at the same time. Do you know what direction that backend is going in? In my experience with VMs, they are always looked after by some host iptables rules for safety, and sometimes NAT rules depending on how they are to be visible outside, and with policy routing at times too. It would be great if those facilities still worked, and unfortunate if the new backend was only usable in quite limited configurations. -- Jamie