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 6440C439CE; Fri, 26 Jan 2024 09:12:59 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2EF89402D0; Fri, 26 Jan 2024 09:12:59 +0100 (CET) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id 0E54740270 for ; Fri, 26 Jan 2024 09:12:57 +0100 (CET) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id AB73526B18 for ; Fri, 26 Jan 2024 09:12:56 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 9F29E26A38; Fri, 26 Jan 2024 09:12:56 +0100 (CET) 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.4 required=5.0 tests=ALL_TRUSTED,AWL, T_SCC_BODY_TEXT_LINE autolearn=disabled version=4.0.0 X-Spam-Score: -1.4 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 56D9A26AB3; Fri, 26 Jan 2024 09:12:54 +0100 (CET) Message-ID: <97893aa5-4e13-4761-9fcb-214b3819bc16@lysator.liu.se> Date: Fri, 26 Jan 2024 09:12:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: rte_atomic_*_explicit Content-Language: en-US To: Honnappa Nagarahalli , Tyler Retzlaff , =?UTF-8?Q?Morten_Br=C3=B8rup?= Cc: "dev@dpdk.org" , Tyler Retzlaff , "konstantin.v.ananyev@yandex.ru" , nd , =?UTF-8?Q?Mattias_R=C3=B6nnblom?= References: <0e268757-8368-456f-ba2f-10a1969c498f@lysator.liu.se> <98CBD80474FA8B44BF855DF32C47DC35E9F1A2@smartserver.smartshare.dk> <20240125223438.GA22922@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= In-Reply-To: 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-01-26 02:37, Honnappa Nagarahalli wrote: > > >> >> On Thu, Jan 25, 2024 at 11:10:47PM +0100, Morten Br�rup wrote: >>>> From: Mattias R�nnblom [mailto:hofors@lysator.liu.se] >>>> Sent: Thursday, 25 January 2024 19.54 >>>> >>>> Why do rte_stdatomic.h functions have the suffix "_explicit"? >>>> Especially >>>> since there aren't any wrappers for the implicit variants. >>>> >>>> More to type, more to read. >>> >>> They have the "_explicit" suffix to make their names similar to those in >> stdatomic.h. >>> >>> You might consider their existence somewhat temporary until C11 stdatomics >> can be fully phased in, so there's another argument for similar names. (This >> probably does not happen as long as compilers generate slower code for C11 >> stdatomics than with their atomic built-ins.) >> >> yes, there was feedback at the time it was. >> >> * we should *not* have non-explicit versions of the macros >> * the atomic generic functions should be named to match C11 standard >> with a rte_ prefix. > This was mainly done to ensure that users think through the memory ordering they want to use. This also matches with the compiler atomic built-ins. Without explicit, it is sequentially consistent memory order. > "This" is referring to the first bullet only, correct? You don't have to distinguish between implicit and explicit if you only have explicit. >> >>> >>>> >>>> When was this API introduced? Shouldn't it say "experimental" >>>> somewhere? >>> >>> They were introduced as part of the migration to C11. >>> I suppose they were not marked experimental because they replaced >> something we didn't want anymore (the compiler built-ins for atomics, e.g. >> __atomic_load_n()). I don't recall if we discussed experimental marking or not. >> >> i don't think we discussed it since they're wrapper macros. >> >>> >>> >>> Reverse paper trail: >>> https://git.dpdk.org/dpdk/log/lib/eal/include/rte_stdatomic.h >>> https://patchwork.dpdk.org/project/dpdk/patch/1692738045-32363-2-git- >> send-email-roretzla@linux.microsoft.com/ >>> https://patchwork.dpdk.org/project/dpdk/patch/1692738045-32363-2-git- >> send-email-roretzla@linux.microsoft.com/ >>>