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 CE19243FD1; Wed, 8 May 2024 08:47:09 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 87DB240A6E; Wed, 8 May 2024 08:47:09 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id 75267402AF for ; Wed, 8 May 2024 08:47:07 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 0F4548F66 for ; Wed, 8 May 2024 08:47:07 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 005948F91; Wed, 8 May 2024 08:47:06 +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 8410D8EF7; Wed, 8 May 2024 08:47:05 +0200 (CEST) Message-ID: <355b3d73-94a8-4734-8934-22081d6e7b11@lysator.liu.se> Date: Wed, 8 May 2024 08:47:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC v7 3/6] eal: add exactly-once bit access functions To: =?UTF-8?Q?Morten_Br=C3=B8rup?= , =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , dev@dpdk.org Cc: Heng Wang , Stephen Hemminger , Tyler Retzlaff References: <20240502055706.112443-2-mattias.ronnblom@ericsson.com> <20240505083737.118649-1-mattias.ronnblom@ericsson.com> <20240505083737.118649-4-mattias.ronnblom@ericsson.com> <98CBD80474FA8B44BF855DF32C47DC35E9F426@smartserver.smartshare.dk> Content-Language: en-US From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F426@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-05-07 21:17, Morten Brørup wrote: >> From: Mattias Rönnblom [mailto:mattias.ronnblom@ericsson.com] >> Sent: Sunday, 5 May 2024 10.38 >> >> Add test/set/clear/assign/flip functions which prevents certain >> compiler optimizations and guarantees that program-level memory loads >> and/or stores will actually occur. >> >> These functions are useful when interacting with memory-mapped >> hardware devices. >> >> The "once" family of functions does not promise atomicity and provides >> no memory ordering guarantees beyond the C11 relaxed memory model. > > In another thread, Stephen referred to the extended discussion on memory models in Linux kernel documentation: > https://www.kernel.org/doc/html/latest/core-api/wrappers/memory-barriers.html > > Unlike the "once" family of functions in this RFC, the "once" family of functions in the kernel also guarantee memory ordering, specifically for memory-mapped hardware devices. The document describes the rationale with examples. > What more specifically did you have in mind? READ_ONCE() and WRITE_ONCE()? They give almost no guarantees. Very much relaxed. I've read that document. What you should keep in mind if you read that document, is that DPDK doesn't use the kernel's memory model, and doesn't have the kernel's barrier and atomics APIs. What we have are an obsolete, miniature look-alike in and something C11-like in . My general impression is that DPDK was moving in the C11 direction memory model-wise, which is not the model the kernel uses. > It makes me think that DPDK "once" family of functions should behave similarly. I think they do already. Also, rte_bit_once_set() works as the kernel's __set_bit(). > Alternatively, if the "once" family of functions cannot be generically implemented with a memory ordering that is optimal for all use cases, drop this family of functions, and instead rely on the "atomic" family of functions for interacting with memory-mapped hardware devices. > >> >> RFC v7: >> * Fix various minor issues in documentation. >> >> RFC v6: >> * Have rte_bit_once_test() accept const-marked bitsets. >> >> RFC v3: >> * Work around lack of C++ support for _Generic (Tyler Retzlaff). >> >> Signed-off-by: Mattias Rönnblom >> Acked-by: Morten Brørup >> Acked-by: Tyler Retzlaff >> --- >