From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH v2 00/31] Implement user mode network for kvm tools
Date: Sat, 2 Jul 2011 12:30:47 +0200
Message-ID: <20110702103047.GF17482@elte.hu>
References: <1309423279-3093-1-git-send-email-asias.hejun@gmail.com>
 <BANLkTi=_Bp-f5ZFDytTrwxFi39JJeEF0bQ@mail.gmail.com>
 <4E0C96FF.4090801@codemonkey.ws>
 <4E0D1238.3020506@gmail.com>
 <20110701115308.GJ20990@elte.hu>
 <27C3F9A0-8814-41A4-A45E-05A9B57DC139@suse.de>
 <1309599956.21962.23.camel@jaguar>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Alexander Graf <agraf@suse.de>, Asias He <asias.hejun@gmail.com>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Stefan Hajnoczi <stefanha@gmail.com>,
	Cyrill Gorcunov <gorcunov@gmail.com>,
	Sasha Levin <levinsasha928@gmail.com>,
	Prasad Joshi <prasadjoshi124@gmail.com>, kvm@vger.kernel.org
To: Pekka Enberg <penberg@kernel.org>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx3.mail.elte.hu ([157.181.1.138]:35329 "EHLO mx3.mail.elte.hu"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1754084Ab1GBKa6 (ORCPT <rfc822;kvm@vger.kernel.org>);
	Sat, 2 Jul 2011 06:30:58 -0400
Content-Disposition: inline
In-Reply-To: <1309599956.21962.23.camel@jaguar>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>


* Pekka Enberg <penberg@kernel.org> wrote:

> On Fri, 2011-07-01 at 15:46 +0200, Alexander Graf wrote:
> > > That's pretty impressive (if it does not come at the expensive of 
> > > features that Qemu's slirp code has) - and the thing is that we don't 
> > > actually have to implement the vast majority of TCP-IP features, 
> > > because the transport between the guest and the host is obviously 
> > > reliable.
> > 
> > I don't see how it would. Once you overrun device buffers, you have to
> > do something. Either you drop packets or you stall the guest. I'd
> > usually prefer the former :).
> 
> If we make the buffers large enough, will this matter in practice?
> 
> > > This patch-set turned out to be a *lot* more simple than i first 
> > > thought it would end up.
> > > 
> > > Simpler also means potentially faster and potentially more secure.
> > > 
> > > ( The lack of ipv6 is not something we should worry about too much, 
> > >  ipv4 should scale up to a couple of hundred thousand virtual
> > >  machines per box, right? )
> > 
> > Well, if the system you're trying to connect to supports ipv4, 
> > sure. If it doesn't, tough luck :).
> 
> Does that mean that the guests would effectively be ipv4-only? 
> That'd be unfortunate.

The guest will effectively be NAT-ed anyway, with it on a private 
network in essence (where the DHCP server gives a dynamic IP), so it 
does not matter at all whether it's using ipv4 or ipv6 for its NAT 
connectivity.

ipv6 might matter for TUN-ed connections, where the guest might be 
visible externally as well.

Unless i'm missing some important ipv6 usecase.

Also, is there any fundamental reason why ipv6 packets couldnt be 
recognized with time? So if there's demand, it could be added.

Thanks,

	Ingo