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 D9CEF43F6C; Thu, 2 May 2024 23:26:36 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A2B77402C9; Thu, 2 May 2024 23:26:36 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id 4A807402C4 for ; Thu, 2 May 2024 23:26:35 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 3020311784 for ; Thu, 2 May 2024 23:26:34 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 0A894116E6; Thu, 2 May 2024 23:26:34 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL, T_SCC_BODY_TEXT_LINE autolearn=disabled version=4.0.0 X-Spam-Score: -1.3 Received: from [192.168.1.59] (h-62-63-215-114.A163.priv.bahnhof.se [62.63.215.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 089AD116E3; Thu, 2 May 2024 23:26:31 +0200 (CEST) Message-ID: Date: Thu, 2 May 2024 23:26:31 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC v2] net/af_packet: make stats reset reliable To: Stephen Hemminger Cc: Ferruh Yigit , "John W. Linville" , Thomas Monjalon , dev@dpdk.org, =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , =?UTF-8?Q?Morten_Br=C3=B8rup?= References: <20240425174617.2126159-1-ferruh.yigit@amd.com> <20240426143848.2280689-1-ferruh.yigit@amd.com> <108e0c40-33e7-4eed-83de-eaedee454480@lysator.liu.se> <7e5dd3cd-ea50-4aea-a350-d88f46854172@amd.com> <422dd5a6-4ed6-4ae5-b613-b22a7cf6f77d@amd.com> <758132fe-fc44-4c06-8e54-c0439f3a693f@lysator.liu.se> <20240502112602.27d55fb8@hermes.local> Content-Language: en-US From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= In-Reply-To: <20240502112602.27d55fb8@hermes.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP 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 2024-05-02 20:26, Stephen Hemminger wrote: > On Thu, 2 May 2024 19:37:28 +0200 > Mattias Rönnblom wrote: > >>> >>> Do we need to declare count as '_Atomic', I wasn't planning to make >>> variable _Atomic. This way assignment won't introduce any memory barrier. >>> >> >> To use atomics in DPDK, the current requirements seems to be to use >> RTE_ATOMIC(). That macro expands to _Atomic in enable_stdatomic=true >> builds, and nothing otherwise. >> >> Carefully crafted code using atomics will achieved the same performance >> and be more correct than the non-atomic variant. However, in practice, I >> think the non-atomic variant is very likely to produce the desired results. > > You are confusing atomic usage for thread safety, with the necessity > of compiler barriers. > Are you suggesting that program-level C11 atomic stores risk being delayed, indefinitely? I could only find a draft version of the standard, but there 7.17.3 says "Implementations should make atomic stores visible to atomic loads within a reasonable amount of time." An atomic relaxed store will be much cheaper than a compiler barrier. > Stats should not be volatile. Sure, and I also don't think compiler barriers should be needed.