From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 9FBD28E7B for ; Mon, 12 Oct 2015 11:56:49 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 12 Oct 2015 02:56:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,671,1437462000"; d="scan'208";a="808903215" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga001.fm.intel.com with ESMTP; 12 Oct 2015 02:56:48 -0700 Received: from fmsmsx153.amr.corp.intel.com (10.18.125.6) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 12 Oct 2015 02:56:48 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by FMSMSX153.amr.corp.intel.com (10.18.125.6) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 12 Oct 2015 02:56:47 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.96]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.194]) with mapi id 14.03.0248.002; Mon, 12 Oct 2015 17:56:40 +0800 From: "Xie, Huawei" To: Yuanhan Liu , Steffen Bauch , Nikita Kalyazin Thread-Topic: [dpdk-dev] [PATCH v5 resend 07/12] virtio: resolve for control queue Thread-Index: AQHRAd6SqPMUap3NIE+thTrs2kpB0w== Date: Mon, 12 Oct 2015 09:56:39 +0000 Message-ID: References: <1442589061-19225-1-git-send-email-yuanhan.liu@linux.intel.com> <1442589061-19225-8-git-send-email-yuanhan.liu@linux.intel.com> <20150920121748-mutt-send-email-mst@redhat.com> <20150921063647.GQ2339@yliu-dev.sh.intel.com> <20151008153205.GB21145@kalyazin.rnd.samsung.ru> <5616D736.2040108@steffenbauch.de> <20151012083956.GF3115@yliu-dev.sh.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.237.220.129] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v5 resend 07/12] virtio: resolve for control queue X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 09:56:50 -0000 On 10/12/2015 10:33 AM, Xie, Huawei wrote:=0A= > On 10/12/2015 9:39 AM, Yuanhan Liu wrote:=0A= >> On Thu, Oct 08, 2015 at 10:51:02PM +0200, Steffen Bauch wrote:=0A= >>> On 10/08/2015 05:32 PM, Nikita Kalyazin wrote:=0A= >>>> Hi Yuanhan,=0A= >>>>=0A= >>>>=0A= >>>> As I understand, the dead loop happened here (virtio_send_command):=0A= >>>> while (vq->vq_used_cons_idx =3D=3D vq->vq_ring.used->idx) {=0A= > Nikita:=0A= >=0A= > Didn't review the whole patch, but happen to find a serious problem in= =0A= > the code snippet here, as volatile isn't used, compiler will assume the= =0A= > memory will not be changed outside and do only one comparison.=0A= >=0A= > Try add volatile prefix, and it might fix your problem.=0A= Read other mails in this thread, if the specific queue is due to wrong=0A= queue index.=0A= Fix the volatile in the code, otherwise if first time no match, the code=0A= will go to dead loop directly and no chance to compare again in=0A= optimized code.=0A= >>>> rte_rmb();=0A= >>>> usleep(100);=0A= >>>> }=0A= >>>>=0A= >>>> Could you explain why wrong config reading caused that and how correct= reading helps to avoid?=0A= >> Wrong config reading results to wrong config->max_virtqueue_pairs, which= =0A= >> ends up with wrong ctrl vq index being set:=0A= >>=0A= >> PMD: virtio_send_command(): vq->vq_queue_index =3D 37120=0A= >>=0A= >> Note that you need enable CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_INIT to see abo= ve=0A= >> debug log.=0A= >>=0A= >> That is to say we are waiting for the backend to consume a non-exist=0A= >> queue, and that's how the dead loop comes.=0A= >>=0A= >>=0A= >>> Hi,=0A= >>>=0A= >>> I just recognized that this dead loop is the same one that I have=0A= >>> experienced (see=0A= >>> http://dpdk.org/ml/archives/dev/2015-October/024737.html for=0A= >>> reference). Just applying the changes in this patch (only 07/12)=0A= >>> will not fix the dead loop at least in my setup.=0A= >> Try to enable CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_INIT, and dump more log?=0A= >>=0A= >> --yliu=0A= >>=0A= >=0A= =0A=