From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40000) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQfD8-0000A9-Bw for qemu-devel@nongnu.org; Fri, 12 Apr 2013 10:44:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UQfD3-0006Ou-QU for qemu-devel@nongnu.org; Fri, 12 Apr 2013 10:44:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40257) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQfD3-0006OK-I4 for qemu-devel@nongnu.org; Fri, 12 Apr 2013 10:44:13 -0400 Message-ID: <51681DAA.3000503@redhat.com> Date: Fri, 12 Apr 2013 16:43:54 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <20130411134820.GA24942@redhat.com> <5166C19A.1040402@linux.vnet.ibm.com> <20130411143718.GC24942@redhat.com> <5166CDAD.8060807@redhat.com> <20130411145632.GA2280@redhat.com> <5166F7AE.8070209@linux.vnet.ibm.com> <20130411191533.GA25515@redhat.com> <51671DFF.80904@linux.vnet.ibm.com> <20130412104802.GA23467@redhat.com> <5167E797.2050103@redhat.com> <20130412112553.GB23467@redhat.com> In-Reply-To: <20130412112553.GB23467@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH RDMA support v5: 03/12] comprehensive protocol documentation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org, "Michael R. Hines" , owasserm@redhat.com, abali@us.ibm.com, mrhines@us.ibm.com, gokul@us.ibm.com Il 12/04/2013 13:25, Michael S. Tsirkin ha scritto: > On Fri, Apr 12, 2013 at 12:53:11PM +0200, Paolo Bonzini wrote: >> Il 12/04/2013 12:48, Michael S. Tsirkin ha scritto: >>> 1. You have two protocols already and this does not make sense in >>> version 1 of the patch. >> >> It makes sense if we consider it experimental (add x- in front of >> transport and capability) and would like people to play with it. >> >> Paolo > > But it's not testable yet. I see problems just reading the > documentation. Author thinks "ulimit -l 10000000000" on both source and > destination is just fine. This can easily crash host or cause OOM > killer to kill QEMU. So why is there any need for extra testers? Fix > the major bugs first. > > There's a similar issue with device assignment - we can't fix it there, > and despite being available for years, this was one of two reasons that > has kept this feature out of hands of lots of users (and assuming guest > has lots of zero pages won't work: balloon is not widely used either > since it depends on a well-behaved guest to work correctly). I agree assuming guest has lots of zero pages won't work, but I think you are overstating the importance of overcommit. Let's mark the damn thing as experimental, and stop making perfect the enemy of good. Paolo