From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: Raw vs. tap
Date: Thu, 15 Oct 2009 17:48:19 +0200
Message-ID: <20091015154819.GA8783@redhat.com>
References: <4AD5DD6B.2030703@codemonkey.ws>
	<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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: kvm-devel <kvm@vger.kernel.org>, qemu-devel@nongnu.org,
	Paul Brook <paul@codesourcery.com>,
	Jens Osterkamp <jens@linux.vnet.ibm.com>,
	Sridhar Samudrala <sri@us.ibm.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Return-path: <qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org>
Content-Disposition: inline
In-Reply-To: <4AD73D3A.4060708@codemonkey.ws>
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
List-Id: kvm.vger.kernel.org

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.

> Regards,
>
> Anthony Liguori