From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <i.maximets@samsung.com> Received: from mailout1.w1.samsung.com (mailout1.w1.samsung.com [210.118.77.11]) by dpdk.org (Postfix) with ESMTP id 6A0DF5A30 for <dev@dpdk.org>; Fri, 18 Mar 2016 13:28:44 +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 <0O4800BULINVVB70@mailout1.w1.samsung.com> for dev@dpdk.org; Fri, 18 Mar 2016 12:28:43 +0000 (GMT) X-AuditID: cbfec7f4-f79026d00000418a-22-56ebf47a95e8 Received: from eusync2.samsung.com ( [203.254.199.212]) by eucpsbgm1.samsung.com (EUCPMTA) with SMTP id C0.2C.16778.A74FBE65; Fri, 18 Mar 2016 12:28:42 +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 <0O4800HWHINUYE50@eusync2.samsung.com>; Fri, 18 Mar 2016 12:28:42 +0000 (GMT) To: "Xie, Huawei" <huawei.xie@intel.com> References: <1456314438-4021-1-git-send-email-i.maximets@samsung.com> <1456314438-4021-2-git-send-email-i.maximets@samsung.com> <C37D651A908B024F974696C65296B57B4C677A7D@SHSMSX101.ccr.corp.intel.com> <56EBD718.8010604@samsung.com> <C37D651A908B024F974696C65296B57B4C677D03@SHSMSX101.ccr.corp.intel.com> <56EBDAD1.1090608@samsung.com> <C37D651A908B024F974696C65296B57B4C677F4C@SHSMSX101.ccr.corp.intel.com> <56EBDFBE.3010502@samsung.com> <C37D651A908B024F974696C65296B57B4C67825C@SHSMSX101.ccr.corp.intel.com> <56EBE9AE.9070400@samsung.com> <56EBF256.8040409@samsung.com> Cc: "dev@dpdk.org" <dev@dpdk.org> From: Ilya Maximets <i.maximets@samsung.com> Message-id: <56EBF47A.9090901@samsung.com> Date: Fri, 18 Mar 2016 15:28:42 +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: <56EBF256.8040409@samsung.com> Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsVy+t/xK7pVX16HGezbbm3x7tN2Jov2mWeZ HJg8fi1YyuqxeM9LpgCmKC6blNSczLLUIn27BK6MqTcOMhbsF654tuYYYwNju0AXIyeHhICJ xKed+1ghbDGJC/fWs3UxcnEICSxllOg7dJwJwnnBKHHl8hUWkCphgWCJDWueMIPYIgIaEmee bGKBKDrDIrF66XM2kASzgKLEp22zwRrYBHQkTq0+wtjFyMHBK6Al0bqAHSTMIqAq0XhjPpgt KhAhcbizC8zmFRCU+DH5Hlgrp4C2RN+TvUwgrcwCehL3L2pBTJeX2LzmLfMERoFZSDpmIVTN QlK1gJF5FaNoamlyQXFSeq6hXnFibnFpXrpecn7uJkZIUH7Zwbj4mNUhRgEORiUe3hdVr8OE WBPLiitzDzFKcDArifCe/QQU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzjt31/sQIYH0xJLU7NTU gtQimCwTB6dUA6PySzXWSRHO61ek60X9qGuatU9mxuY/WdYbfxzRvPpyzp/lPQm6XRd3hYid nXJt3RWG80onJ/DN3GTmGNd0vty17bD2+XX2HSrKGdmzls8o2Z8xrWmO968Ht3QeCcpv61lr 5HDHotdylcqSrT1bn6h//u/dwrmhO3qhafLaJV9PPEvaFxF02iVMiaU4I9FQi7moOBEAd1SI SEYCAAA= Subject: Re: [dpdk-dev] [PATCH RFC v3 1/3] 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 <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Fri, 18 Mar 2016 12:28:44 -0000 CC to list. On 18.03.2016 15:19, Ilya Maximets wrote: > > > On 18.03.2016 14:42, Ilya Maximets wrote: >> On 18.03.2016 14:30, Xie, Huawei wrote: >>> On 3/18/2016 7:00 PM, Ilya Maximets wrote: >>>> On 18.03.2016 13:47, Xie, Huawei wrote: >>>>> On 3/18/2016 6:39 PM, Ilya Maximets wrote: >>>>>> On 18.03.2016 13:27, Xie, Huawei wrote: >>>>>>> On 3/18/2016 6:23 PM, Ilya Maximets wrote: >>>>>>>> On 18.03.2016 13:08, Xie, Huawei wrote: >>>>>>>>> On 2/24/2016 7:47 PM, Ilya Maximets wrote: >>>>>>>>>> * Wait until it's our turn to add our buffer >>>>>>>>>> @@ -979,7 +979,7 @@ rte_vhost_dequeue_burst(struct virtio_net *dev, uint16_t queue_id, >>>>>>>>>> entry_success++; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> - rte_compiler_barrier(); >>>>>>>>>> + rte_smp_rmb(); >>>>>>>>> smp_rmb()? >>>>>>>> There is no such function 'smp_rmb' in DPDK. >>>>>>>> But: >>>>>>>> .../arch/arm/rte_atomic.h:#define rte_smp_rmb() rte_rmb() >>>>>>>> .../arch/ppc_64/rte_atomic.h:#define rte_smp_rmb() rte_compiler_barrier() >>>>>>>> .../arch/tile/rte_atomic.h:#define rte_smp_rmb() rte_compiler_barrier() >>>>>>>> .../arch/x86/rte_atomic.h:#define rte_smp_rmb() rte_compiler_barrier() >>>>>>> I mean shoudn't be rte_smp_wmb()? >>>>>> No. Here we need to be sure that copying of data from descriptor to >>>>>> our local mbuf completed before 'vq->used->idx += entry_success;'. >>>>>> >>>>>> Read memory barrier will help us with it. >>>>>> >>>>>> In other places write barriers used because copying performed in >>>>>> opposite direction. >>>>> What about the udpate to the used ring? >>>> Next line is the only place where this vq->used->idx accessed. >>>> So, there must be no issues. >>> >>> The update to the used ring entries, happened before the update to the >>> used ring index. >> >> Oh. Sorry. In that case we need full barrier here because we need reads and >> writes both completed before updating of used->idx: >> rte_smp_mb(); > > Hmmm.. But as I see, rte_smp_mb is a real mm_fence on x86. May be the pair > of barriers will be better here: > rte_smp_rmb(); > rte_smp_wmb(); > > It is normal because next increment uses read and write. So, we don't need to > synchronize reads with writes here. > >> >>> >>>> >>>>>>>>>> vq->used->idx += entry_success; >>>>>>>>>> vhost_log_used_vring(dev, vq, offsetof(struct vring_used, idx), >>>>>>>>>> sizeof(vq->used->idx)); >>>>>>>>>> -- 2.5.0 >>>>>>> >>>>> >>>>> >>> >>> >>>