From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MRMLv-0001cv-4M for qemu-devel@nongnu.org; Thu, 16 Jul 2009 04:30:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MRMLq-0001ao-51 for qemu-devel@nongnu.org; Thu, 16 Jul 2009 04:30:06 -0400 Received: from [199.232.76.173] (port=40939 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MRMLp-0001al-Vi for qemu-devel@nongnu.org; Thu, 16 Jul 2009 04:30:02 -0400 Received: from mx20.gnu.org ([199.232.41.8]:30870) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MRMLp-0008PA-IB for qemu-devel@nongnu.org; Thu, 16 Jul 2009 04:30:01 -0400 Received: from fwil.voltaire.com ([193.47.165.2] helo=exil.voltaire.com) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MRMLg-00082m-NA for qemu-devel@nongnu.org; Thu, 16 Jul 2009 04:29:53 -0400 Message-ID: <4A5EE4EE.1090308@voltaire.com> Date: Thu, 16 Jul 2009 11:29:34 +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> <4A54B0F1.3070201@voltaire.com> <20090715203806.GF3056@shareable.org> In-Reply-To: <20090715203806.GF3056@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: > When using a bridge, you set the IP address on the bridge itself (for example, br0). DHCP runs on the bridge itself, so does the rest of the Linux host stack, although you can use raw sockets on the other interfaces. But reading and controlling the hardware is done on the interfaces. So if you have some program like NetworkManager which checks if you have a wire plugged into eth0, it has to read eth0 to get the wire status, but it has to run DHCP on br0. Yes, I understand that if the guest want to communicate with the host in a bridged environment, the IP has to be set on the bridge. With "DHCP" do you refer to dhcp server or to dhcp relay or something else? I assume its not a server, since you mentioned a NON NAT environment. > A bridge is quite simple to configure. Unfortunately because Linux requires all the IP configuration on the bridge device, but network device control on the network device, bridges don't work well with automatic configuration tools. seems like this scheme/problem is similar to bonding, where the IP configuration is done to the bond device but people may still want to do control the slave devices, I am not sure why such tools need the device to have an IP, but it seems less relevant for this thread. > Have you measured it? Yes, I will send soon some data. > Unfortunately that's usually impossible. Most switches don't do U turns, and a lot of simple networks don't have any switches except a home router Again, as I wrote, the U turn can be done in three places: software bridge, virtual HW bridge inside the NIC, or at an external switch. With virtualuzation becoming more common, options 2 and 3 will be more and more available, where the packet socket approach is valid for both of them. > No, it makes performance _much_ worse if you have packets leaving the host, do a U turn and come back on the same link. Much better to use a bridge inside the host. Probably ten times faster because host's internal networking is much faster than a typical gigabit link :-) My benchmark was focusing on packets per second for VM <--> world and not on VM/VM communication. I tend to think that with KVM and the raw mode or kernel virtio-net backend with both requiring U turn, the VM/VM performance will be no less in most if not all measures (namely, packets per second, cpu utilization, bandwidth, latency, etc). Still, its quite clear that both these mode can be useful for people that want to max the VM <---> world communication performance. > Sometimes it would be useful to send it outside the host and U turn, but not very often; only for diagnostics I would think. And even that can be done with Linux bridges, using VLANs :-) mmm, I wasn't sure if you refer to Linux vlans (8021q devices) or the Qemu vlan... can you elaborate? > If you don't need any host<->VM networking, maybe a raw packet socket is faster > But are you sure it's faster? I'd want to see measurements before I believe it. fair enough Or.