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 94AA05A35 for ; Wed, 1 Apr 2015 16:40:21 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 01 Apr 2015 07:40:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,504,1422950400"; d="scan'208";a="701572495" Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88]) by fmsmga002.fm.intel.com with ESMTP; 01 Apr 2015 07:40:19 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 1 Apr 2015 22:40:18 +0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.24]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.71]) with mapi id 14.03.0224.002; Wed, 1 Apr 2015 22:40:17 +0800 From: "Xie, Huawei" To: Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH] cast used->idx to volatile Thread-Index: AQHQZWQ7XK9uXNwZJ06D/GCM+7Oz0A== Date: Wed, 1 Apr 2015 14:40:17 +0000 Message-ID: References: <1426925237-8312-1-git-send-email-haifeng.lin@huawei.com> <55191575.5020805@huawei.com> <13730553.gtSSln9O6Y@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] 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] cast used->idx to volatile 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: Wed, 01 Apr 2015 14:40:22 -0000 On 4/1/2015 3:51 PM, Thomas Monjalon wrote:=0A= > 2015-03-30 15:56, Xie, Huawei:=0A= >> On 3/30/2015 5:21 PM, Linhaifeng wrote:=0A= >>> On 2015/3/24 18:06, Xie, Huawei wrote:=0A= >>>> On 3/24/2015 3:44 PM, Linhaifeng wrote:=0A= >>>>> On 2015/3/24 9:53, Xie, Huawei wrote:=0A= >>>>>> On 3/24/2015 9:00 AM, Linhaifeng wrote:=0A= >>>>>>> On 2015/3/23 20:54, Xie, Huawei wrote:=0A= >>>>>>>> We have compiler barrier before and an external function call behi= nd, so we don't need volatile here.=0A= >>>>>>>> Do you meet issue?=0A= >>>>>>>>=0A= >>>>>>> Tx_q is sometimes stopped when we use virtio_net. Because vhost tho= ught there are no buffers in tx_q and virtio_net=0A= >>>>>>> though vhost haven't handle all packets so we have to restart VM to= restore work.=0A= >>>>>>>=0A= >>>>>>> The status in VM is:=0A= >>>>>>> Mar 18 17:11:10 linux-b2ij kernel: [46337.246687] net eth7: virtnet= _poll=0A= >>>>>>> Mar 18 17:11:10 linux-b2ij kernel: [46337.246690] net eth7: receive= _buf=0A= >>>>>>> Mar 18 17:11:10 linux-b2ij kernel: [46337.246693] net eth7: vi->num= =3D239=0A= >>>>>>> Mar 18 17:11:10 linux-b2ij kernel: [46337.246695] net eth7: svq:ava= il->idx=3D52939 used->idx=3D52939 num_free=3D18 num_added=3D0 svq->last_use= d_idx=3D52820=0A= >>>>>>> Mar 18 17:11:10 linux-b2ij kernel: [46337.246699] net eth7: rvq:ava= il->idx=3D36215 used->idx=3D35977 num_free=3D18 num_added=3D0 rvq->last_use= d_idx=3D35977=0A= >>>>>>> Mar 18 17:11:11 linux-b2ij kernel: [46337.901038] net eth7: dev_que= ue_xmit, qdisc->flags=3D4, qdisc->state deactiveed=3D0=0A= >>>>>>> Mar 18 17:11:12 linux-b2ij kernel: [46337.901042] net eth7: dev_que= ue_xmit, txq->state=3D1, stopped=3D1=0A= >>>>>>>=0A= >>>>>>> Why compiler barrier not take effect in our case? Is compiler barri= er depended on -O3 option? We use -O2 option.=0A= >>>>>> compiler barrier always works regardless of the optimization option.= =0A= >>>>>> I don't get your story, but the key thing is, do you check the asm c= ode?=0A= >>>>>> If called from outside as an API, how is it possible it is optimized= ?=0A= >>>>>> there is only one update to used->idx in that function.=0A= >>>>> Do you mean rte_vhost_enqueue_burst also not need cast used->idx to v= olatile ? Why not remove it?=0A= >>>> I checked the code. Seems we can remove. That is another issue.=0A= >>>> For your issue, you meet problem, and submit this this patch, but i am= a=0A= >>>> bit confused it is the root cause. Do you check the asm code that=0A= >>>> volatile is optimized?=0A= >>>>=0A= >>> I had wrote a demo try to find out the different between rte_compiler_b= arrier and volatile.=0A= >>> It seems no any effect on rte_compiler_barrier().=0A= >> Haifeng:=0A= >>=0A= >> I think it doesn't make too much sense to use volatile for local variabl= es.=0A= >>=0A= >> In our rte_vhost_dequeue_burst, there is one memory write to the=0A= >> used->idx, and there is compiler barrier to keep the order.=0A= >> Besides, as an API, how could that memory write to be optimized as=0A= >> register access?=0A= >>=0A= >> Even if you call rte_vhost_dequeue_burst in the same src file, which=0A= >> means in the same translation unit, there is function call after which= =0A= >> has side effect, it still couldn't be optimized.=0A= >>=0A= >> Anyway, could we directly check the asm code of rte_vhost_dequeue_burst= =0A= >> to see whether it is optimized?=0A= > Conclusion is not clear. Is this patch rejected?=0A= >=0A= >=0A= >=0A= so far we have no evidence the code has error so will temporarily reject it= .=0A=