From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MzSgn-00037Y-5L for qemu-devel@nongnu.org; Sun, 18 Oct 2009 06:08:37 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MzSge-00035F-Tl for qemu-devel@nongnu.org; Sun, 18 Oct 2009 06:08:34 -0400 Received: from [199.232.76.173] (port=35268 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MzSge-00034w-F8 for qemu-devel@nongnu.org; Sun, 18 Oct 2009 06:08:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:2703) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MzSgd-0006eQ-Tc for qemu-devel@nongnu.org; Sun, 18 Oct 2009 06:08:28 -0400 Date: Sun, 18 Oct 2009 12:05:54 +0200 From: "Michael S. Tsirkin" Message-ID: <20091018100554.GA8342@redhat.com> References: <20091014142453.GA29798@redhat.com> <20091014151917.GB17062@shareable.org> <20091014155018.GB30179@redhat.com> <1255554600.20366.9.camel@w-sridhar.beaverton.ibm.com> <4AD65684.3010403@codemonkey.ws> <20091015075612.GB32003@redhat.com> <4AD72453.1050209@codemonkey.ws> <20091015150454.GA8620@redhat.com> <4AD73D3A.4060708@codemonkey.ws> <20091015154819.GA8783@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091015154819.GA8783@redhat.com> Subject: [Qemu-devel] Re: Raw vs. tap List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: kvm-devel , qemu-devel@nongnu.org, Paul Brook , Jens Osterkamp , Sridhar Samudrala On Thu, Oct 15, 2009 at 05:48:19PM +0200, Michael S. Tsirkin wrote: > On Thu, Oct 15, 2009 at 10:18:18AM -0500, Anthony Liguori wrote: > > Michael S. Tsirkin wrote: > >> On Thu, Oct 15, 2009 at 08:32:03AM -0500, Anthony Liguori wrote: > >> > >>> Michael S. Tsirkin wrote: > >>> > >>>> On Wed, Oct 14, 2009 at 05:53:56PM -0500, Anthony Liguori wrote: > >>>> > >>>>> I would be much more inclined to consider taking raw and > >>>>> improving the performance long term if guest<->host networking > >>>>> worked. This appears to be a fundamental limitation though and > >>>>> I think it's something that will forever plague users if we > >>>>> include this feature. > >>>>> > >>>> In fact, I think it's fixable with a raw socket bound to a macvlan. > >>>> Would that be enough? > >>>> > >>> What setup does that entail on the part of a user? Wouldn't we be > >>> back to square one wrt users having to run archaic networking > >>> commands in order to set things up? > >>> > >> > >> Unlike bridge, qemu could set up macvlan without disrupting > >> host networking. The only issue would be cleanup if qemu > >> is killed. > >> > > > > But this would require additional features in macvlan, correct? > > Not sure: what is the "this" that you are talking about. > It can already be set up without disturbing host networking. > > > This also only works if a guest uses the mac address assigned to it, > > correct? If a guest was bridging the virtual nic, this would all come > > apart? > > Hmm, you could enable promisc mode, but generally this is true: > if you require bridging, use a bridge. Just to clarify this statement: if bridge in guest does not configure mac filtering on guest uplink (linux bridge by default does not do this now, OTOH macvlan does), bridge in host will perform better in this setup because it learns macs from traffic and does mac filtering in host. > > Regards, > > > > Anthony Liguori