From mboxrd@z Thu Jan  1 00:00:00 1970
From: Pekka Enberg <penberg@kernel.org>
Subject: Re: [PATCH v2 00/31] Implement user mode network for kvm tools
Date: Sat, 02 Jul 2011 12:45:56 +0300
Message-ID: <1309599956.21962.23.camel@jaguar>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Ingo Molnar <mingo@elte.hu>, 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: Alexander Graf <agraf@suse.de>
Return-path: <kvm-owner@vger.kernel.org>
Received: from filtteri5.pp.htv.fi ([213.243.153.188]:40876 "EHLO
	filtteri5.pp.htv.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752076Ab1GBJp6 (ORCPT <rfc822;kvm@vger.kernel.org>);
	Sat, 2 Jul 2011 05:45:58 -0400
In-Reply-To: <27C3F9A0-8814-41A4-A45E-05A9B57DC139@suse.de>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

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.

			Pekka