From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36905) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VGs9i-0004eW-FP for qemu-devel@nongnu.org; Tue, 03 Sep 2013 11:04:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VGs9W-0004Gj-KJ for qemu-devel@nongnu.org; Tue, 03 Sep 2013 11:04:34 -0400 Received: from e39.co.us.ibm.com ([32.97.110.160]:51192) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VGs9W-0004DS-D3 for qemu-devel@nongnu.org; Tue, 03 Sep 2013 11:04:22 -0400 Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 3 Sep 2013 09:03:58 -0600 Message-ID: <5225EEA2.4060908@linux.vnet.ibm.com> Date: Tue, 03 Sep 2013 10:13:54 -0400 From: "Michael R. Hines" MIME-Version: 1.0 References: <20130902124627.GE26177@valinux.co.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-stable][PATCH] rdma: fix multiple VMs parallel migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Frank Yang Cc: Isaku Yamahata , qemu-stable@nongnu.org, qemu-devel@nongnu.org, yamahata@valinux.co.jp, Michael R Hines , pbonzini@redhat.com No top-posting, please. On 09/03/2013 12:20 AM, Frank Yang wrote: > Yes, it depends on low-level implementation. During my earlier test, > using one CQ to send and receive may cause packet loss with heavy load: > the destination thinks it send READY message successfully but the source > still waits for it. This situation always happens when the destination > polls > receive CQE first. > > So I think using only one CQ may cause packet conflict or something > like that, > and it should be the driver bug. However, using two CQs fix the problem. > > This doesn't seem like a very clear answer ..... are you sure its packet loss? The queue pairs are supposed to be reliable - I've never experienced a situation where packets were simply "dropped" for no reason without breaking the connection and putting the QP into an error state. - Michael