From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MOYOs-0000op-6N for qemu-devel@nongnu.org; Wed, 08 Jul 2009 10:45:34 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MOYOn-0000lg-MV for qemu-devel@nongnu.org; Wed, 08 Jul 2009 10:45:33 -0400 Received: from [199.232.76.173] (port=53041 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MOYOn-0000lb-GQ for qemu-devel@nongnu.org; Wed, 08 Jul 2009 10:45:29 -0400 Received: from fwil.voltaire.com ([193.47.165.2]:50073 helo=exil.voltaire.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MOYOm-0006PQ-Vp for qemu-devel@nongnu.org; Wed, 08 Jul 2009 10:45:29 -0400 Message-ID: <4A54B0F1.3070201@voltaire.com> Date: Wed, 08 Jul 2009 17:45:05 +0300 From: Or Gerlitz MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] net: add raw backend References: <20090701162115.GA4555@shareable.org> <4A4CA747.1050509@Voltaire.com> <20090703023911.GD938@shareable.org> <4A534EC4.5030209@voltaire.com> <20090707145739.GB14392@shareable.org> In-Reply-To: <20090707145739.GB14392@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: Herbert Xu , Jan Kiszka , qemu-devel@nongnu.org Jamie Lokier wrote: > The problem is simply what the guest sends goes out on the network and is not looped backed to the host network stack, and vice versa. So if your host is 192.168.1.1 and is running a DNS server (say), and the guest is 192.168.1.2, when the guest sends queries to 192.168.1.1 the host won't see those queries. Same if you're running an FTP server on the host and the guest wants to connect to it, etc. It also means multiple guests can't see each other, for the same reason. So it's much less useful than bridging, where the guests and host can all see each other and connect to each other. I wasn't sure to follow if your example refers to the case when networking uses the bridge or NAT. If its bridge, then through which bridge interface the packet arrives the host stack? say you have a bridge whose attached interfaces are tap1(VM1), tap2(VM2) and eth0(NIC), in your example did you mean that the host IP address is assigned to the bridge interface? or you were referring a NAT based scheme? > Unfortunately, bridging is a pain to set up, if your host has any complicated or automatic network configuration already. As you said bridging requires more configuration, but not less important the performance (packets per second and cpu utilization) one can get with bridge+tap is much lower vs what you get with the raw mode approach. All in all, its clear that with this approach VM/VM and VM/Host communication would have to get switched either at the NIC (e.g SR/IOV capable NICs supporting a virtual bridge) or at an external switch and make a U turn. There's a bunch of reasons why people would like to do that, among them performance boost, the ability to shape, manage and monitor VM/VM traffic in external switches and more. > It would be really nice to find a way which has the advantages of both. Either by adding a different bridging mode to Linux, where host interfaces can be configured for IP and the bridge hangs off the host interface, or by a modified tap interface, or by an alternative > pcap/packet-like interface which forwards packets in a similar way to bridging. It seems that this will not yield the performance improvement we can get with going directly to the NIC. But if someone comes up and makes such a mode working, it can be merged into qemu as well along with the raw mode. Or.