From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) by dpdk.org (Postfix) with ESMTP id 7A58D1B0F8 for ; Tue, 15 Jan 2019 09:29:18 +0100 (CET) Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id 20190115082917euoutp0233dd9fd0b971b359687fa6fbdd5626c5~5_E058CnF3041730417euoutp026 for ; Tue, 15 Jan 2019 08:29:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20190115082917euoutp0233dd9fd0b971b359687fa6fbdd5626c5~5_E058CnF3041730417euoutp026 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1547540957; bh=y1euKDf8cDz8/z8uJ1RnUowlXuwU3kv+LUP060HdJk0=; h=Subject:To:Cc:From:Date:In-Reply-To:References:From; b=hdYa8muJoFOKQNHks8Qah9C9eXYcroOjPgDd4yW4INyo/wo3cLxLjlzMvZoqKkrki oD/9Z6+2EZNfna1C2lF2d/i1Hme2WXcALz55JQHa4MVeoCrD4eGGXszB4XRml3kKMV bzoQAV4Xc7grBGeH2ZqdXno10123lQ71DZ/zfuYg= Received: from eusmges1new.samsung.com (unknown [203.254.199.242]) by eucas1p1.samsung.com (KnoxPortal) with ESMTP id 20190115082917eucas1p1b45a4f7122efdaef40a7f9f1aa54981c~5_E0ciZ881869818698eucas1p1L; Tue, 15 Jan 2019 08:29:17 +0000 (GMT) Received: from eucas1p2.samsung.com ( [182.198.249.207]) by eusmges1new.samsung.com (EUCPMTA) with SMTP id 4C.8F.04441.CD99D3C5; Tue, 15 Jan 2019 08:29:16 +0000 (GMT) Received: from eusmtrp1.samsung.com (unknown [182.198.249.138]) by eucas1p1.samsung.com (KnoxPortal) with ESMTPA id 20190115082916eucas1p1876b8c4c3d90dbd052dcee757a321228~5_EzokS0B1273812738eucas1p1M; Tue, 15 Jan 2019 08:29:16 +0000 (GMT) Received: from eusmgms2.samsung.com (unknown [182.198.249.180]) by eusmtrp1.samsung.com (KnoxPortal) with ESMTP id 20190115082915eusmtrp17f7cd524040a395567696a2aaa214f49~5_EzZk7hn1767817678eusmtrp1O; Tue, 15 Jan 2019 08:29:15 +0000 (GMT) X-AuditID: cbfec7f2-5e3ff70000001159-43-5c3d99dca19c Received: from eusmtip1.samsung.com ( [203.254.199.221]) by eusmgms2.samsung.com (EUCPMTA) with SMTP id BB.BA.04128.BD99D3C5; Tue, 15 Jan 2019 08:29:15 +0000 (GMT) Received: from [106.109.129.180] (unknown [106.109.129.180]) by eusmtip1.samsung.com (KnoxPortal) with ESMTPA id 20190115082915eusmtip1b0733c139f4536a1c9204cfe94fad7e8~5_EynaqZu1282712827eusmtip1U; Tue, 15 Jan 2019 08:29:15 +0000 (GMT) To: Shahaf Shuler , "Michael S. Tsirkin" Cc: "dev@dpdk.org" , Maxime Coquelin , Xiao Wang , "jfreimann@redhat.com" , Tiwei Bie , Zhihong Wang , Jason Wang , "xiaolong.ye@intel.com" , "alejandro.lucero@netronome.com" , Daniel Marcovitch From: Ilya Maximets Message-ID: <0e415915-2a36-6950-4b11-adf91bdf2b0b@samsung.com> Date: Tue, 15 Jan 2019 11:29:14 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTcRTH/d17t11H135Ow8MqipFFUc6g6ILLTApHUGj9E2WP5S4qOotN LQtyheWyJyuYipEoPqY9IJ1GRelWmpqKmqOwWmFUrnLplm+0bTfJ/z7nex7fc+DQpKRdIKVT MzI5bYYqXSYUUw0tk90b3hdtTYx0lsnZrtFKgn03XiNih0cbCfZN/qSIrex1E2zX3QqKbbn0 lGLnppwCdqBkF2vRzxHs8282ETvzczNb12MkYhjlVGmFQFn+dIhQfjXZCKXp8mdS6XrWL1Re q69B8cIDYoWaS0/N5rTy6KPiFHtj4okP+JTds1ePypgCFEgD3gR5jhFUgMS0BFcjcDuKRHzg QTDcfI7iAzeCcWe9YL7FZdBTPpbgKgQF5VE8jyDovnTUxyH4EFS35RM+DsUJ0G9s9Q8isYWE sav5pC8hxOuhvfYF8jGDo8HTfM8/lMLhcKuzzq8vwfvB4KgV8jXB0Fb0xV8T6DVo6mzyG5A4 DM57zAKeV0DjrxLSZwb4owi+F94X8lvvAHN3/z8OAWdrvYjnZdBx8wrFcy448oYQ32xAYLLO EnxiG9T/6PI20F6HtfDgsZyXt8P0ZBXlkwEHwdtfwfwOQWBsMJG8zIDhooSvXgXTzVUkz1J4 N+wW3UCy4gWXFS+4pnjBNcX/fUsRVYPCuCydJpnTbczgTkboVBpdVkZyRNJxzUPk/bCO2dbR R+hP7zErwjSSLWJi7igSJQJVti5HY0VAk7JQJjvWKzFqVc5pTnv8iDYrndNZ0VKakoUxZwI+ HZTgZFUml8ZxJzjtfJagA6V6dHtstuqDRs286njkLHsoTbI0v37Sp2QUth4zN2pf3ZR5oXJP 9TCVlvs7buLQgFzKHranusL1A9XX4/HyU+ra7S+tP9HK2HTzTI7Bs0YbGdl3oO50LBd7/chO ww5RYUDCTNxq40pb3D7b7FXxm86zg7tljvDFqgmLomvQFbUFyyhdimrjOlKrU/0Fb5QsOV0D AAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPIsWRmVeSWpSXmKPExsVy+t/xu7q3Z9rGGCzuN7Y492kZk8XN76vY Ld592s5kcaX9J7vFskufmSzOrVnKYnGscw+Lxf9fr1gtbs/xstja8J/JYv/zw+wWf96YWmy+ OInJgdfj14KlrB6L97xk8ng2/TCTx/Tuh8we7/ddZfPo27KKMYAtSs+mKL+0JFUhI7+4xFYp 2tDCSM/Q0kLPyMRSz9DYPNbKyFRJ384mJTUnsyy1SN8uQS/j2vaYgrsCFde+BDUwLuLtYuTk kBAwkXjf0cDSxcjFISSwlFHie8d2RoiElMSPXxdYIWxhiT/Xutggit4zSqztmMUCkhAWiJVY cbKdCcQWEQiUuLZpDjtIEbPATmaJxzdus0J0LGCRaO/4yg5SxSagI3Fq9RGwFbwCdhJfDq4F m8QioCox5exmsLioQITE2ZfroGoEJU7OfAJWwwm07cDZA2DbmAXUJf7Mu8QMYYtLNH1ZyQph y0tsfzuHeQKj0Cwk7bOQtMxC0jILScsCRpZVjCKppcW56bnFRnrFibnFpXnpesn5uZsYgZG7 7djPLTsYu94FH2IU4GBU4uF1mG8TI8SaWFZcmXuIUYKDWUmEt8wJKMSbklhZlVqUH19UmpNa fIjRFOi5icxSosn5wKSSVxJvaGpobmFpaG5sbmxmoSTOe96gMkpIID2xJDU7NbUgtQimj4mD U6qBcVYjX9wlyTt3vV49MX14xWjC9NePNRs39T/IVVYo/aI7a1N8q+jzOztizoVel2je8tZ2 RdEDM4aKheZvzOS5XpaWem4KXvAm07rRJfpyR5CIj4NzbO0Ll/0/t7wXXifGP9Nnm/e0q1lu jgr7olfbnOqert0w9+KcJovlsvfLwiU1/s7USX/crcRSnJFoqMVcVJwIADjQg8XyAgAA X-CMS-MailID: 20190115082916eucas1p1876b8c4c3d90dbd052dcee757a321228 X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20181226163717eucas1p15276eb45e35abe2c9cf3e7c1e0050823 X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20181226163717eucas1p15276eb45e35abe2c9cf3e7c1e0050823 References: <20181214153812.3878-1-i.maximets@samsung.com> <20181226163712.31596-1-i.maximets@samsung.com> <2832c88f-9b43-997c-5937-ef5ae6482fd5@samsung.com> <20190109104855-mutt-send-email-mst@kernel.org> Subject: Re: [dpdk-dev] [PATCH v2] net/virtio: add platform memory ordering feature support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 08:29:18 -0000 On 15.01.2019 9:33, Shahaf Shuler wrote: > Thursday, January 10, 2019 10:37 PM, Shahaf Shuler: >> Subject: RE: [dpdk-dev] [PATCH v2] net/virtio: add platform memory >> ordering feature support >> >> Wednesday, January 9, 2019 5:50 PM, Michael S. Tsirkin: >>> alejandro.lucero@netronome.com; Daniel Marcovitch >>> >>> Subject: Re: [dpdk-dev] [PATCH v2] net/virtio: add platform memory >>> ordering feature support >>> >>> On Wed, Jan 09, 2019 at 05:34:38PM +0300, Ilya Maximets wrote: >>>> virtio_mb() is really heavy. I'd like to avoid it somehow, but I >>>> don't know how to do this yet. >>> >>> Linux driver doesn't avoid it either. >> >> I understand v3 was merged but still would like to continue the discuss and >> make sure all is clear and agreed. >> >> Form patch [1] description it is very clear why we need the rte_smp_mb() >> barrier. >> However I am not sure why this barrier is interoperate into rte_mb in case of >> vDPA. In vDPA case, both read of the user ring and write of the avail index >> are for local cached memory. >> The only write which is to uncachable memory (device memory) is the notify >> itself. >> >> As I mentioned, there is a need to have a store fence before doing the >> notify, but from different reasons. So vDPA use case and need Is a bit >> different than what presented in [1]. > > Any answer? > It is pity if we add redundant barriers which will degrade the driver performance. Sorry for late responses. Have a lot of work with OVS right now. Regarding your question. Current code looks like this: 1. Update ring. 2. virtio_wmb() 3. Update idx. 4. virtio_mb() 5. read flags. 6. notify. virtio_mb() is here to avoid reordering of steps 3 and 5. i.e. we need a full barrier to ensure the order between store (idx update) and load (reading the flags). Otherwise we could miss the notification. We can't avoid the barrier here, because even x86 does not guarantee the ordering of the local load with earlier local store. > >> >> [1] >> https://patches.dpdk.org/patch/49545/ >> >>> >>> -- >>> MST > >