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 3FB90439CE; Fri, 26 Jan 2024 09:07:15 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1222140289; Fri, 26 Jan 2024 09:07:15 +0100 (CET) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id 4350540270 for ; Fri, 26 Jan 2024 09:07:13 +0100 (CET) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id C3CD026A26 for ; Fri, 26 Jan 2024 09:07:12 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id B856326A9F; Fri, 26 Jan 2024 09:07:12 +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 EA3E0269D7; Fri, 26 Jan 2024 09:07:10 +0100 (CET) Message-ID: Date: Fri, 26 Jan 2024 09:07:10 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: rte_atomic_*_explicit Content-Language: en-US To: =?UTF-8?Q?Morten_Br=C3=B8rup?= , dev@dpdk.org Cc: Tyler Retzlaff , konstantin.v.ananyev@yandex.ru, =?UTF-8?Q?Mattias_R=C3=B6nnblom?= References: <0e268757-8368-456f-ba2f-10a1969c498f@lysator.liu.se> <98CBD80474FA8B44BF855DF32C47DC35E9F1A2@smartserver.smartshare.dk> From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F1A2@smartserver.smartshare.dk> 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-25 23:10, 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. > OK, so to avoid a situation where someone accidentally misinterpret rte_atomic_fetch_add(&counter, 1, rte_memory_order_relaxed); as what, exactly? If you have a wrapper, why not take the opportunity and reap some benefits from this and fix/extend the standard API, making it a better fit for your application. Like removing the redundant "_explicit", "fetch"-less add/sub, maybe and a function for single-writer atomic add (non-atomic read + non-atomic add + atomic store), etc. Prohibiting implicit operations was done already, so it's already now not a straight-off copy of the standard API. > 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.) > To me, it seems reasonable a wrapper API should stay as long as it provide a benefit over the standard API. One could imagine that being a long time. I imagine some DPDK developers being tired of migrating from one atomics API to another. -> GCC built-ins (-> attempted C11 stdatomics?) -> . Now you are adding a future "-> CXY atomics" move as well, and with that it also seems natural to add a change back to a wrapper or complementary API, when CXY didn't turned out good enough for some particular platform, or when some non-complaint compiler comes along. I suggested fixing the original API, or at least have a wrapper API, already at the point DPDK moved to direct GCC built-in calls. Then we wouldn't have had this atomics API ping-pong. >> >> 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. > > > 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/ >