From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id D04C8F94 for ; Thu, 27 Apr 2017 10:52:24 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D1235804F8; Thu, 27 Apr 2017 08:52:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com D1235804F8 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=maxime.coquelin@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com D1235804F8 Received: from [10.36.112.43] (ovpn-112-43.ams2.redhat.com [10.36.112.43]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8A1A018A28; Thu, 27 Apr 2017 08:52:22 +0000 (UTC) To: Yuanhan Liu Cc: Zhiyong Yang , dev@dpdk.org, ciara.loftus@intel.com, =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= References: <1493274893-40764-1-git-send-email-zhiyong.yang@intel.com> <57212715-6192-dba2-418a-2418a5d14953@redhat.com> <20170427082047.GL11512@yliu-dev.sh.intel.com> From: Maxime Coquelin Message-ID: <0bb0c833-1178-c587-8085-12137ebd91d5@redhat.com> Date: Thu, 27 Apr 2017 10:52:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <20170427082047.GL11512@yliu-dev.sh.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Thu, 27 Apr 2017 08:52:24 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH] vhost: fix MQ fails to startup X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 08:52:25 -0000 On 04/27/2017 10:20 AM, Yuanhan Liu wrote: > On Thu, Apr 27, 2017 at 09:56:47AM +0200, Maxime Coquelin wrote: >> Hi Zhiyong, >> >> +Marc-André >> >> On 04/27/2017 08:34 AM, Zhiyong Yang wrote: >>> vhost since dpdk17.02 + qemu2.7 and above will cause failures of >>> new connection when negotiating to set MQ. (one queue pair works >>> well).Because there exist some bugs in qemu code when introducing >>> VHOST_USER_PROTOCOL_F_REPLY_ACK to qemu. when dealing with the vhost >>> message VHOST_USER_SET_MEM_TABLE for the second time, qemu indeed >>> doesn't send the messge (The message needs to be sent only once)but >>> still will be waiting for dpdk's reply ack, then, qemu is always >>> freezing. DPDK code works in the right way. >> >> I'm looking at Qemu's vhost_user_set_mem_table() function, but fail to >> see how it could wait for the reply-ack if it didn't send the >> VHOST_USER_SET_MEM_TABLE request before. >> >>> But the feature >>> VHOST_USER_PROTOCOL_F_REPLY_ACK has to be disabled by default at the >>> dpdk side in order to avoid the feature support of DPDK + qemu at >>> the same time. if doing like that, MQ can works well. Once Qemu bugs >>> have been fixed and upstreamed, we can enable it. >> >> The problem is for DPDK to detect whether bug is fixed in Qemu. >> Maybe only way would be to have a new protocol feature flag, which is >> not really its role. > > Wouldn't that be an overkill, judging that REPLY_ACK is not a must > feature? Yes, maybe. But it was introduced to fix (possible) race conditions: https://lists.gnu.org/archive/html/qemu-devel/2016-07/msg06173.html Note that I planned to use this feature for the device IOTLB implementation to let the backend decide whether it wants the IOTLB misses synchronous or asynchronous. But I can still change the protocol spec to make this behavior specific to this request. Maxime > --yliu >