From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout1.w1.samsung.com (mailout1.w1.samsung.com [210.118.77.11]) by dpdk.org (Postfix) with ESMTP id 9176B28F2 for ; Mon, 21 Mar 2016 05:49:57 +0100 (CET) Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout1.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0O4D00I4VHF7G520@mailout1.w1.samsung.com> for dev@dpdk.org; Mon, 21 Mar 2016 04:49:55 +0000 (GMT) X-AuditID: cbfec7f4-f796c6d000001486-60-56ef7d7380d5 Received: from eusync2.samsung.com ( [203.254.199.212]) by eucpsbgm1.samsung.com (EUCPMTA) with SMTP id E2.82.05254.37D7FE65; Mon, 21 Mar 2016 04:49:55 +0000 (GMT) Received: from [106.109.129.180] by eusync2.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id <0O4D0080SHF6QQ20@eusync2.samsung.com>; Mon, 21 Mar 2016 04:49:55 +0000 (GMT) To: Yuanhan Liu 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> Cc: dev@dpdk.org, Huawei Xie , Dyasly Sergey From: Ilya Maximets Message-id: <56EF7D72.1050108@samsung.com> Date: Mon, 21 Mar 2016 07:49:54 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-version: 1.0 In-reply-to: <20160318124102.GV979@yliu-dev.sh.intel.com> Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsVy+t/xK7rFte/DDE5tVLJ492k7k0X7zLNM FpNnS1lcn3CB1YHF49eCpawei/e8ZPKYdzLQo2/LKsYAligum5TUnMyy1CJ9uwSujD2vL7AW vOKrOPdxHUsDYztPFyMnh4SAicSaxd9ZIGwxiQv31rN1MXJxCAksZZTYcmsHlPOCUeL77jus XYwcHMICnhLXfmSBNIgI6Eo8nbOOFaJmI6PE0bNNjCAJZoFoiedrDjCB2GwCOhKnVh8Bi/MK aEmsnHKHGcRmEVCVeP69ix3EFhWIkDjcCWHzCghK/Jh8D+wiTgFLiUvz5jKC7GUW0JO4f1EL Yry8xOY1b5knMArMQtIxC6FqFpKqBYzMqxhFU0uTC4qT0nMN9YoTc4tL89L1kvNzNzFCAvfL DsbFx6wOMQpwMCrx8HK8fxsmxJpYVlyZe4hRgoNZSYT3rf/7MCHelMTKqtSi/Pii0pzU4kOM 0hwsSuK8c3e9DxESSE8sSc1OTS1ILYLJMnFwSjUw5pyzn+fwgT1linjqbdsMgTkGGf8KnStv 1h2wPhDluFvC59kzg6ePk6ov+TRLsHw6olZtrOkVZXqu1i1+/rIXwk1vJ3yodnzC7rkmZElU G+vH5aJyq1R8joWKfbFvKuKZJrpm5aR6S8ekouvbwzI1GIzCWe8fO8BWaxJjtrSFa0YDz6qq WHElluKMREMt5qLiRADt9TJPWAIAAA== 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 04:49:57 -0000 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") virtio >> 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_rxtx.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 queue_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 != res_start_idx)) >> @@ -565,7 +565,7 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16_t queue_id, >> >> nr_used = 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, uint16_t queue_id, >> sizeof(vq->used->ring[used_idx])); >> } >> >> - rte_compiler_barrier(); >> + rte_smp_wmb(); >> + rte_smp_rmb(); > > rte_smp_mb? rte_smp_mb() is a real mm_fence() on x86. And we don't need to synchronize reads with writes here, only reads with reads and writes with writes. It is enough because next increment uses read and write. Pair of barriers is better because it will not impact on performance on x86. Best regards, Ilya Maximets.