From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id BA6832C48 for ; Mon, 21 Mar 2016 18:25:50 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga101.jf.intel.com with ESMTP; 21 Mar 2016 10:25:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,372,1455004800"; d="scan'208";a="673298254" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by FMSMGA003.fm.intel.com with ESMTP; 21 Mar 2016 10:25:49 -0700 Received: from FMSMSX109.amr.corp.intel.com (10.18.116.9) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 21 Mar 2016 10:25:49 -0700 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by fmsmsx109.amr.corp.intel.com (10.18.116.9) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 21 Mar 2016 10:25:48 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.136]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.24]) with mapi id 14.03.0248.002; Tue, 22 Mar 2016 01:25:46 +0800 From: "Xie, Huawei" To: "Ananyev, Konstantin" , Ilya Maximets , Yuanhan Liu CC: "dev@dpdk.org" , Dyasly Sergey Thread-Topic: [dpdk-dev] [PATCH v4] vhost: use SMP barriers instead of compiler ones. Thread-Index: AdGDlrPatFeITSYZTUuTr96dWwZoxg== Date: Mon, 21 Mar 2016 17:25:46 +0000 Message-ID: References: <1456314438-4021-2-git-send-email-i.maximets@samsung.com> <1458303833-14815-1-git-send-email-i.maximets@samsung.com> <20160318124102.GV979@yliu-dev.sh.intel.com> <56EF7D72.1050108@samsung.com> <2601191342CEEE43887BDE71AB97725836B1F296@irsmsx105.ger.corp.intel.com> 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 Subject: Re: [dpdk-dev] [PATCH v4] vhost: use SMP barriers instead of compiler ones. 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, 21 Mar 2016 17:25:51 -0000 On 3/21/2016 10:07 PM, Ananyev, Konstantin wrote:=0A= >=0A= >> -----Original Message-----=0A= >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ilya Maximets=0A= >> Sent: Monday, March 21, 2016 4:50 AM=0A= >> To: Yuanhan Liu=0A= >> Cc: dev@dpdk.org; Xie, Huawei; Dyasly Sergey=0A= >> Subject: Re: [dpdk-dev] [PATCH v4] vhost: use SMP barriers instead of co= mpiler ones.=0A= >>=0A= >>=0A= >>=0A= >> On 18.03.2016 15:41, Yuanhan Liu wrote:=0A= >>> On Fri, Mar 18, 2016 at 03:23:53PM +0300, Ilya Maximets wrote:=0A= >>>> Since commit 4c02e453cc62 ("eal: introduce SMP memory barriers") virti= o=0A= >>>> uses architecture dependent SMP barriers. vHost should use them too.= =0A= >>>>=0A= >>>> Fixes: 4c02e453cc62 ("eal: introduce SMP memory barriers")=0A= >>>>=0A= >>>> Signed-off-by: Ilya Maximets =0A= >>>> ---=0A= >>>> lib/librte_vhost/vhost_rxtx.c | 7 ++++---=0A= >>>> 1 file changed, 4 insertions(+), 3 deletions(-)=0A= >>>>=0A= >>>> diff --git a/lib/librte_vhost/vhost_rxtx.c b/lib/librte_vhost/vhost_rx= tx.c=0A= >>>> index b4da665..859c669 100644=0A= >>>> --- a/lib/librte_vhost/vhost_rxtx.c=0A= >>>> +++ b/lib/librte_vhost/vhost_rxtx.c=0A= >>>> @@ -315,7 +315,7 @@ virtio_dev_rx(struct virtio_net *dev, uint16_t que= ue_id,=0A= >>>> rte_prefetch0(&vq->desc[desc_indexes[i+1]]);=0A= >>>> }=0A= >>>>=0A= >>>> - rte_compiler_barrier();=0A= >>>> + rte_smp_wmb();=0A= >>>>=0A= >>>> /* Wait until it's our turn to add our buffer to the used ring. */= =0A= >>>> while (unlikely(vq->last_used_idx !=3D res_start_idx))=0A= >>>> @@ -565,7 +565,7 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16= _t queue_id,=0A= >>>>=0A= >>>> nr_used =3D copy_mbuf_to_desc_mergeable(dev, vq, start, end,=0A= >>>> pkts[pkt_idx]);=0A= >>>> - rte_compiler_barrier();=0A= >>>> + rte_smp_wmb();=0A= >>>>=0A= >>>> /*=0A= >>>> * Wait until it's our turn to add our buffer=0A= >>>> @@ -923,7 +923,8 @@ rte_vhost_dequeue_burst(struct virtio_net *dev, ui= nt16_t queue_id,=0A= >>>> sizeof(vq->used->ring[used_idx]));=0A= >>>> }=0A= >>>>=0A= >>>> - rte_compiler_barrier();=0A= >>>> + rte_smp_wmb();=0A= >>>> + rte_smp_rmb();=0A= >>> rte_smp_mb?=0A= >> rte_smp_mb() is a real mm_fence() on x86. And we don't need to synchroni= ze reads with=0A= >> writes here, only reads with reads and writes with writes. It is enough = because next=0A= >> increment uses read and write. Pair of barriers is better because it wil= l not impact=0A= >> on performance on x86.=0A= > Not arguing about that particular patch, just a question:=0A= > Why do we have:=0A= > #define rte_smp_mb() rte_mb()=0A= =0A= Konstantine, actually smp_mb is defined as mfence while smp_r/wmb are=0A= defined as barrier in kernel_src/arch/x86/include/asm/barrier.h.=0A= =0A= > for x86?=0A= > Why not just:=0A= > #define rte_smp_mb() rte_compiler_barrier()=0A= > here?=0A= > I meant for situations when we do need real mfence, there is an 'rte_mb' = to use.=0A= > Konstantin=0A= >=0A= >> Best regards, Ilya Maximets.=0A= =0A=