From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6A106A0524; Fri, 6 Nov 2020 10:22:19 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CA45F5953; Fri, 6 Nov 2020 10:22:17 +0100 (CET) Received: from smtpbgeu1.qq.com (smtpbgeu1.qq.com [52.59.177.22]) by dpdk.org (Postfix) with ESMTP id 1B4C45946 for ; Fri, 6 Nov 2020 10:22:16 +0100 (CET) X-QQ-mid: bizesmtp22t1604654529t98azwky Received: from jiawenwu (unknown [183.129.236.74]) by esmtp6.qq.com (ESMTP) with id ; Fri, 06 Nov 2020 17:22:08 +0800 (CST) X-QQ-SSF: 01400000002000C0D000000A0000000 X-QQ-FEAT: oLU221C22Z9hONuRhtFCEH7GXFoLLFEr8JP7Xz5PUTJ81UoBCrQzXB4GvC4W2 MajP3gA6A1RDLij1a6e0slX7ra+l11HzrEPGdm47RNEBjtSfaz+WvgUys5BtejB2BeaqWiS 6mIGBhvULeihdNt4xI+nqK5EhmuZ4m0fG7lwoCOR/pQcoK0CHAsw7GhfaxQfy6SS3sntiBX ebAwX7wraHuVChSu/IGmWHKvooe2aPSc0l+Bb2bwQuiqmJ6PFHguojKxrqivJKteeTZinQl lFKvubL0xYk1OeQ4hFxKnbCj4D1w39RLDzq/e+WLgOG3Z4NjS2ARnjVwAfvKM+FMdkSd+5k bYOpZhcoUUOjdUH9+k= X-QQ-GoodBg: 2 From: "Jiawen Wu" To: "'Honnappa Nagarahalli'" Cc: , , , "'nd'" , , "'Ferruh Yigit'" References: <20201019085415.82207-1-jiawenwu@trustnetic.com> <003e01d6b351$709871d0$51c95570$@trustnetic.com> <3558935.noZgFSCOjD@thomas> In-Reply-To: Date: Fri, 6 Nov 2020 17:22:08 +0800 Message-ID: <004401d6b41e$4d6bb050$e84310f0$@trustnetic.com>+DEBC84495741A0C1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHa8hVbTdzNZG5niZylkY0c60fr5gH4p1zCAWPt9sICDMSAxgGrtmmmqXmlQjA= Content-Language: zh-cn X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:trustnetic.com:qybgforeign:qybgforeign7 X-QQ-Bgrelay: 1 Subject: Re: [dpdk-dev] [PATCH v4 00/58] net: txgbe PMD 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Friday, November 6, 2020 2:29 PM, Honnappa Nagarahalli wrote: > > > > > > +Cc Konstantin and Honnappa for guidance > > > > 05/11/2020 09:55, Jiawen Wu: > > > On Thursday, November 5, 2020 9:55 AM, Jiawen Wu wrote: > > > > On Thursday, November 5, 2020 1:24 AM, Ferruh Yigit wrote: > > > > > On 11/3/2020 11:08 PM, Thomas Monjalon wrote: > > > > > > When pulling in the main branch, I see some checkpatches > > > > > > warnings (in order of criticality): > > > > > > Using rte_smp_[r/w]mb > > > > > > Using rte_panic/rte_exit > > > > > > Using compiler attribute directly > > > > > > > > > > > > Please could you fix them (at least first two) before the second series? > > [...] > > > > > > I saw ' rte_smp_*mb ' is in the deprecation notices, but there is no > > > function can be an alternative. > > > I would like to use 'rte_atomic_thread_fence(__ATOMIC_ACQUIRE)' to > > > replace 'rte_smp_rmb()', is it the correct usage? > Yes, rte_atomic_thread_fence(__ATOMIC_ACQUIRE) is the correct code to > replace 'rte_smp_rmb()'. > > However, I took a look at the code and it is not clear to me if the barrier is > required or if it is in the correct place. > Thanks for guidance. I want to add the barrier at the time before reading descriptors in Rx scan, to synchronize with the hardware. Actually I don't really understand the usage of this function. Could you please tell me more details?