From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id F032BA0503; Fri, 6 May 2022 09:03:17 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9395040395; Fri, 6 May 2022 09:03:17 +0200 (CEST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by mails.dpdk.org (Postfix) with ESMTP id 218A84014F for ; Fri, 6 May 2022 09:03:15 +0200 (CEST) Received: from dggpeml500024.china.huawei.com (unknown [172.30.72.55]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4KvhNB0fsjzhYwZ; Fri, 6 May 2022 15:02:50 +0800 (CST) Received: from [127.0.0.1] (10.67.100.224) by dggpeml500024.china.huawei.com (7.185.36.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Fri, 6 May 2022 15:03:12 +0800 Subject: Re: [PATCH v5] eal: add seqlock To: Honnappa Nagarahalli , =?UTF-8?Q?Mattias_R=c3=b6nnblom?= , "dev@dpdk.org" CC: "thomas@monjalon.net" , David Marchand , "onar.olsen@ericsson.com" , nd , "konstantin.ananyev@intel.com" , "mb@smartsharesystems.com" , "stephen@networkplumber.org" , "hofors@lysator.liu.se" , Ola Liljedahl References: <3e9b0560-9306-0826-4911-1cf0e72c30d9@lysator.liu.se> <20220501140327.265128-1-mattias.ronnblom@ericsson.com> <5d53f008-1895-436d-60a2-b4e0c5937182@huawei.com> From: fengchengwen Message-ID: <579809ca-3e26-8b84-be01-fa089ccd6011@huawei.com> Date: Fri, 6 May 2022 15:03:12 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.100.224] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpeml500024.china.huawei.com (7.185.36.10) X-CFilter-Loop: Reflected X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 2022/5/6 13:19, Honnappa Nagarahalli wrote: > > >>>>> +__rte_experimental >>>>> +static inline bool >>>>> +rte_seqlock_read_retry(const rte_seqlock_t *seqlock, uint32_t >>>>> +begin_sn) { >>>>> + uint32_t end_sn; >>>>> + >>>>> + /* An odd sequence number means the protected data was being >>>>> + * modified already at the point of the rte_seqlock_read_begin() >>>>> + * call. >>>>> + */ >>>>> + if (unlikely(begin_sn & 1)) >>>>> + return true; >>>>> + >>>>> + /* make sure the data loads happens before the sn load */ >>>>> + rte_atomic_thread_fence(__ATOMIC_ACQUIRE); >>>> >>>> In ARMv8, the rte_atomic_thread_fence(__ATOMIC_ACQUIRE) and >>>> rte_smp_rmb() both output 'dma ishld' >>>> Suggest use rte_smp_rmb(), please see below comment. >>> rte_smp_xxx APIs are deprecated. Please check [1] >>> >>> [1] https://www.dpdk.org/blog/2021/03/26/dpdk-adopts-the-c11-memory- >> model/ >> >> Got it, thanks >> >> And I have a question about ARM: why can't find the >> parameter(rte_atomic_thread_fence(?)) corresponding to 'dmb ishst'? >> I tried __ATOMIC_RELEASE/ACQ_REL/SEQ_CST and can't find it. > 'dmb ishst' prevents store-store reordering. However, '__atomic_thread_fence' (with various memory ordering) requires more stronger barrier [1]. For this seqlock scenario, I think it's OK to use 'dmb ishst' in rte_seqlock_write_lock() instead of use rte_atomic_thread_fence(__ATOMIC_RELEASE), but the 'dmb ishst' havn't corresponding rte_atomic_thread_fence() wrapper, so in this case, we could only use stronger barrier. Since the community has decided to use the C11 memory mode API, it is probably clear about the preceding scenarios (using stronger barrier). I have no comment. > > [1] https://preshing.com/20130922/acquire-and-release-fences/ >> >>> >>> >>> >