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 64D32439E3; Sat, 27 Jan 2024 20:08:11 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D62F9402E0; Sat, 27 Jan 2024 20:08:10 +0100 (CET) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id D3A80402D5 for ; Sat, 27 Jan 2024 20:08:09 +0100 (CET) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 681745975 for ; Sat, 27 Jan 2024 20:08:09 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 4F7785A82; Sat, 27 Jan 2024 20:08:09 +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 78C3B5A80; Sat, 27 Jan 2024 20:08:07 +0100 (CET) Message-ID: Date: Sat, 27 Jan 2024 20:08:07 +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?= , honnappa.nagarahalli@arm.com References: <0e268757-8368-456f-ba2f-10a1969c498f@lysator.liu.se> <98CBD80474FA8B44BF855DF32C47DC35E9F1A2@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F1A8@smartserver.smartshare.dk> From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F1A8@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-26 11:52, Morten Brørup wrote: >> From: Mattias Rönnblom [mailto:hofors@lysator.liu.se] >> Sent: Friday, 26 January 2024 09.07 >> >> 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. > > Yes, more migrations seem to be on the roadmap. > > We can take the opportunity to change direction now, and decide to keep the API long term. > Then it would need more documentation (basically copying function descriptions from ), and the functions could have the "_explicit" suffix removed (macros with the suffix could be added for backwards compatibility), and more functions - like the ones you suggested above - could be added. > > What do people think? > 1. Keep considering a temporary wrapper for until compilers reach some undefined level of maturity, or > 2. Consider stable, clean it up (remove "_explicit" suffix), add documentation to the macros, and extend it. > > Living in a DPDK-only environment, I would prefer option 2; but if mixing DPDK code with non-DPDK code (that uses ) it might be weird. > I think DPDK should have its own atomics API, with C11-style naming and semantics, where there is an overlap, and keep it until the heat death of the universe. Is there an example of a large-scale project of the OS kernel or network stack kind that *doesn't* have its own atomics API (which wraps/extends C11 atomics, and/or uses compiler built-ins or in-line assembler)? fd.io VPP, OpenDataPlane (ODP) and the Linux kernel all have custom APIs. >> >> 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. > > The decision back then might have been too hasty, and based on incomplete assumptions. > Please shout louder next time you think a mistake is in the making. > >> >>>> >>>> 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. > > In hindsight, they should probably have been marked "experimental". >