From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id C6F2F2C6B for ; Mon, 21 Mar 2016 15:07:36 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP; 21 Mar 2016 07:07:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,372,1455004800"; d="scan'208";a="673201578" Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by FMSMGA003.fm.intel.com with ESMTP; 21 Mar 2016 07:07:35 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.35]) by IRSMSX107.ger.corp.intel.com ([169.254.10.137]) with mapi id 14.03.0248.002; Mon, 21 Mar 2016 14:07:33 +0000 From: "Ananyev, Konstantin" To: Ilya Maximets , Yuanhan Liu CC: "dev@dpdk.org" , "Xie, Huawei" , Dyasly Sergey Thread-Topic: [dpdk-dev] [PATCH v4] vhost: use SMP barriers instead of compiler ones. Thread-Index: AQHRgRNU6EJ69+oAZESZLDhiFfLMEZ9jWBEAgACZqaA= Date: Mon, 21 Mar 2016 14:07:32 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725836B1F296@irsmsx105.ger.corp.intel.com> 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> In-Reply-To: <56EF7D72.1050108@samsung.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZWJiY2U4NmItZGVhOC00NGU5LWJlNDMtMmZmZDBiMzYwYmUwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6ImZnSUFYNnhPbGU2aDVzNHVyXC9oU2dHUGVMdzZkWlVpTko3SFNKQ2UwT0ZrPSJ9 x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.182] 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 14:07:37 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ilya Maximets > Sent: Monday, March 21, 2016 4:50 AM > To: Yuanhan Liu > Cc: dev@dpdk.org; Xie, Huawei; Dyasly Sergey > Subject: Re: [dpdk-dev] [PATCH v4] vhost: use SMP barriers instead of com= piler ones. >=20 >=20 >=20 > On 18.03.2016 15:41, Yuanhan Liu wrote: > > On Fri, Mar 18, 2016 at 03:23:53PM +0300, Ilya Maximets wrote: > >> Since commit 4c02e453cc62 ("eal: introduce SMP memory barriers") virti= o > >> uses architecture dependent SMP barriers. vHost should use them too. > >> > >> Fixes: 4c02e453cc62 ("eal: introduce SMP memory barriers") > >> > >> Signed-off-by: Ilya Maximets > >> --- > >> lib/librte_vhost/vhost_rxtx.c | 7 ++++--- > >> 1 file changed, 4 insertions(+), 3 deletions(-) > >> > >> diff --git a/lib/librte_vhost/vhost_rxtx.c b/lib/librte_vhost/vhost_rx= tx.c > >> index b4da665..859c669 100644 > >> --- a/lib/librte_vhost/vhost_rxtx.c > >> +++ b/lib/librte_vhost/vhost_rxtx.c > >> @@ -315,7 +315,7 @@ virtio_dev_rx(struct virtio_net *dev, uint16_t que= ue_id, > >> rte_prefetch0(&vq->desc[desc_indexes[i+1]]); > >> } > >> > >> - rte_compiler_barrier(); > >> + rte_smp_wmb(); > >> > >> /* Wait until it's our turn to add our buffer to the used ring. */ > >> while (unlikely(vq->last_used_idx !=3D res_start_idx)) > >> @@ -565,7 +565,7 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16= _t queue_id, > >> > >> nr_used =3D copy_mbuf_to_desc_mergeable(dev, vq, start, end, > >> pkts[pkt_idx]); > >> - rte_compiler_barrier(); > >> + rte_smp_wmb(); > >> > >> /* > >> * Wait until it's our turn to add our buffer > >> @@ -923,7 +923,8 @@ rte_vhost_dequeue_burst(struct virtio_net *dev, ui= nt16_t queue_id, > >> sizeof(vq->used->ring[used_idx])); > >> } > >> > >> - rte_compiler_barrier(); > >> + rte_smp_wmb(); > >> + rte_smp_rmb(); > > > > rte_smp_mb? >=20 > rte_smp_mb() is a real mm_fence() on x86. And we don't need to synchroniz= e reads with > writes here, only reads with reads and writes with writes. It is enough b= ecause next > increment uses read and write. Pair of barriers is better because it will= not impact > on performance on x86. Not arguing about that particular patch, just a question: Why do we have: #define rte_smp_mb() rte_mb() for x86? Why not just: #define rte_smp_mb() rte_compiler_barrier() here? I meant for situations when we do need real mfence, there is an 'rte_mb' to= use. Konstantin >=20 > Best regards, Ilya Maximets.