From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout3.w1.samsung.com (mailout3.w1.samsung.com [210.118.77.13]) by dpdk.org (Postfix) with ESMTP id C2545C3BA for ; Wed, 21 Oct 2015 17:42:15 +0200 (CEST) Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout3.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0NWK00AYRUAEGB70@mailout3.w1.samsung.com> for dev@dpdk.org; Wed, 21 Oct 2015 16:42:14 +0100 (BST) X-AuditID: cbfec7f5-f794b6d000001495-2b-5627b25642c1 Received: from eusync1.samsung.com ( [203.254.199.211]) by eucpsbgm2.samsung.com (EUCPMTA) with SMTP id 09.E0.05269.652B7265; Wed, 21 Oct 2015 16:42:14 +0100 (BST) Received: from localhost ([106.109.131.58]) by eusync1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id <0NWK0036PUAD0660@eusync1.samsung.com>; Wed, 21 Oct 2015 16:42:14 +0100 (BST) Date: Wed, 21 Oct 2015 18:42:04 +0300 From: Nikita Kalyazin To: Bruce Richardson Message-id: <20151021154204.GB27896@kalyazin.rnd.samsung.ru> References: <1445350066-31818-1-git-send-email-n.kalyazin@samsung.com> <20151020142951.GA18496@bricha3-MOBL3> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-disposition: inline In-reply-to: <20151020142951.GA18496@bricha3-MOBL3> X-Priority: 3 User-Agent: Mutt/1.5.23 (2014-03-12) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsVy+t/xy7phm9TDDI5t57K4scre4t2n7UwW k2dLOTB7/FqwlNVj8Z6XTB59W1YxBjBHcdmkpOZklqUW6dslcGXsvXaFqWCBUMW9hYuZGhif 83UxcnBICJhItOxx7GLkBDLFJC7cW88GYgsJLGWU2Hk6DML+yiixcV46iM0ioCpx7Ns7dpBW NgE9idOng0HCIgKGElsXbmUGsZkFzCR+LdrBCmILC4RINCxbBWbzCthI7Fh9mxGkVUggX6Ln pgdEWFDix+R7LCBhZgF1iSlTciGmSEs8+jsDbBGngLHEnSsaEDfySsxof8oCYosKqEhcmfCW fQKj4Cwkg2YhDJqFZNACRuZVjKKppckFxUnpuUZ6xYm5xaV56XrJ+bmbGCEB+3UH49JjVocY BTgYlXh4PyxUCxNiTSwrrsw9xCjBwawkwlvdrR4mxJuSWFmVWpQfX1Sak1p8iFGag0VJnHfm rvchQgLpiSWp2ampBalFMFkmDk6pBkbfml+C+7Y9+Nv/KKpnXkyvwrMbdjJutp+dJjdxPdat bNGtO/zULT0yLG7XsXmXblb4r50z4ZmWy+Rjh+5+OZIoMyf/YYzHmZmbBdkmbTQ/7XzhqNKc 9stPf/zfU3XJhv3W5jYrIeu1GkxXnqrc4VP5vZbrx6ocpqojrCvKTcIn9MjMFdJtEuRTYinO SDTUYi4qTgQAy64+01QCAAA= Cc: dev@dpdk.org, Dyasly Sergey Subject: Re: [dpdk-dev] [PATCH] vhost: call write barrier before used index update 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, 21 Oct 2015 15:42:16 -0000 Hi, > This has been discussed a number of times before on list, and the consensus > seems to be that the correct way to fix this is to introduce a set of specific > barrier operations that insert the correct barrier type on each architecture, > i.e. compiler barriers on IA, and full wmbs on architectures that require that. Linux kernel contains two sets of macros: *mb() and smp_*mb(). As far as I understand, the former are meant to order memory accesses when interacting with peripherals (physical NICs in our case), and the latter - to provide synchronization between CPU cores (applicable for virtual NICs in our case). smp_*mb() for Intel architecture would be a simple compiler barrier, whereas for processors with weaker memory model they may use real barrier instructions. Maybe implementing barriers similar way would work in DPDK as well? -- Best regards, Nikita Kalyazin, n.kalyazin@samsung.com Software Engineer Virtualization Group Samsung R&D Institute Russia Tel: +7 (495) 797-25-00 #3816 Tel: +7 (495) 797-25-03 Office #1501, 12-1, Dvintsev str., Moscow, 127018, Russia On Tue, Oct 20, 2015 at 03:29:51PM +0100, Bruce Richardson wrote: > On Tue, Oct 20, 2015 at 05:07:46PM +0300, Nikita Kalyazin wrote: > > Descriptors that have been put into the used vring must be observable by > > guest earlier than the new used index value. > > Although compiler barrier serves well for Intel architectue here, the > > proper cross-platform solution is to use write barrier before the used > > index is updated. > > > > Signed-off-by: Nikita Kalyazin > > --- > Yes, but no! :-) > > This has been discussed a number of times before on list, and the consensus > seems to be that the correct way to fix this is to introduce a set of specific > barrier operations that insert the correct barrier type on each architecture, > i.e. compiler barriers on IA, and full wmbs on architectures that require that. > > See discussion here: http://dpdk.org/dev/patchwork/patch/4293/ > and in the thread here: http://dpdk.org/ml/archives/dev/2015-March/015202.html > > So correct problem statment, but unfortunately NAK for the implementation. > > Patches for general memory barrier implementation as described above welcome :-) > > Regards, > /Bruce