From mboxrd@z Thu Jan  1 00:00:00 1970
From: Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: Raw vs. tap
Date: Thu, 15 Oct 2009 10:18:18 -0500
Message-ID: <4AD73D3A.4060708@codemonkey.ws>
References: <4ACDF550.1020502@codemonkey.ws>
	<20091014132154.GA29037@redhat.com>
	<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>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: "Michael S. Tsirkin" <mst@redhat.com>
Return-path: <qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org>
In-Reply-To: <20091015150454.GA8620@redhat.com>
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

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?

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?

Regards,

Anthony Liguori