From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MyL4r-0003wT-Jh for qemu-devel@nongnu.org; Thu, 15 Oct 2009 03:48:49 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MyL4n-0003vE-PQ for qemu-devel@nongnu.org; Thu, 15 Oct 2009 03:48:49 -0400 Received: from [199.232.76.173] (port=49903 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MyL4n-0003vB-J2 for qemu-devel@nongnu.org; Thu, 15 Oct 2009 03:48:45 -0400 Received: from fwil.voltaire.com ([193.47.165.2]:11340 helo=exil.voltaire.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MyL4m-0004J1-UH for qemu-devel@nongnu.org; Thu, 15 Oct 2009 03:48:45 -0400 Message-ID: <4AD6D3B9.3060901@Voltaire.com> Date: Thu, 15 Oct 2009 09:48:09 +0200 From: Or Gerlitz MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH-updated] qemu/net: add raw backend References: <20091014143415.GA29937@redhat.com> <4AD5E449.9070301@codemonkey.ws> <20091014151406.GA17062@shareable.org> <4AD5F51E.7040907@codemonkey.ws> <20091014161424.GA30308@redhat.com> <4AD61A31.1080109@codemonkey.ws> In-Reply-To: <4AD61A31.1080109@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Arnd Bergmann , qemu-devel@nongnu.org, "Michael S. Tsirkin" Anthony Liguori wrote: > for every user who understands the limitations of the raw socket > interface and is willing to accept them in order to avoid setting up a > bridge, there will be a dozen who's experience will be worse because > they tried the raw socket interface and it behaved in a way that they didn't expect. limitations can be documented > We aren't talking about adding a feature here. We're talking about > adding something that's supposed to be "easier" but I'm arguing that > it's not easier unless you're a kernel hacker and deeply understand the > limitations of the implementation. Anthony, Its surely a feature, you bypass the bridge/tap and go directly to the NIC. Using sr-iov/vf based nic or macvlan, its software counterpart is simply as running /sbin/ip to create the nic in the macvlan case, or reading a short memo in the sr-iov case. Nothing is kernel hacking, e.g this is being done now all over the place by application engineers of the 10g nic vendors, and as eventually all of them are going to support sr-iov in the coming year. I believe that the Qemu developer community should also look into this near future and allow the adoption of a feature that allows for much less state-full configuration compared to a bridge/tap one and provides better performance. The VMs would get their IP from a DHCP server residing on the network and not the host, this should be acceptable for many users. Or. Or. Or.