From patchwork Sat Mar 2 13:53:21 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Mattias_R=C3=B6nnblom?= X-Patchwork-Id: 738 Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id B03B843C3A; Sat, 2 Mar 2024 15:02:17 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3E8CF4025C; Sat, 2 Mar 2024 15:02:17 +0100 (CET) Received: from EUR03-AM7-obe.outbound.protection.outlook.com (mail-am7eur03on2078.outbound.protection.outlook.com [40.107.105.78]) by mails.dpdk.org (Postfix) with ESMTP id 91724400D5 for ; Sat, 2 Mar 2024 15:02:15 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VDZjPQujd+Yr9i4/Wkueg0kxnynP4Cmw2aBTipgiod9YBD7/NjqEKy1BeHKsBXDdd1NBOGw8lwkTKS3VMKUUT2ZsNPCI0NqjRpI88L7TPSny8zyQlrlGRKAKcqn9De4K5at4D5hSYtqIWpBvKogrm5An7QAXxMaPe8zo8m9YlN18g/DdbR6TbZAU16J/VR0GMjQFVA3bXmJzt1efx247FXGDGJGIvRiE5m7Ve5tjNmw93ev36v48rKJFUs2kTY7eRgBuXv1fvSP+P5JJLKGl5ff1skvPItFONtSdexjnTRS3vn2BbiN8oVLOccht7S3Bz7AjM761e08046yXNGf2wg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=cqEwbYUyjia318T0xzGuco5bB5t77dw1uC1VDzcd+RE=; b=HBwijEROBDF1QuZwTrBciDQawuFpD5CpxNDq8un3Eiv0rCYWs/q8dTvG6YurLOdBKQGbX18q9nQ3Vozzm9kdRyqOQsONjicSaM36JOrcjXKLNnIa3HL88VacSZUFDUWjTiSXvJkQrvDzR/wrsJVB+XGoRvPkbhHCzdlAJ13RG+GV4KOZtI+pbb3u2+jx6E21fgDy+FXv+ncVkNEtqSm7el8WKNw6V7ns7EPNMLeFuFA+zLbBe6pGa2pady0taq72n0dSdoCHU6ctuta1a/JLA0Zb0Rl9u8L9IFlrmODvzvANRGm0K0fratVlhfr5zj2H0aj9vVDMqwDxSd9OD1d/dg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 192.176.1.74) smtp.rcpttodomain=dpdk.org smtp.mailfrom=ericsson.com; dmarc=pass (p=reject sp=reject pct=100) action=none header.from=ericsson.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cqEwbYUyjia318T0xzGuco5bB5t77dw1uC1VDzcd+RE=; b=lJONbcPCZ7mwldR/owVnvrAzj4Y6UJHid+h4YDfXtFCnKMyPTDnIl/IZd5HmMyQ+b2ycV0WtZuxRBzPCe6dNjT3Ul52vkCHLFd+M253TxGOyVd+HmMbgowC3yLiTwdVHVo/GuVTfx3DSDFAJ6cpkY+w9sN1v0aalOwclxo6UnG0LVqlvc9siOCeZ5VFNz9Sz7cRU8V71uDDrc3jsDBokeiA+JKNTsCfN9qIxY7BkoaXs+86EBCkpW43ligTaxy64+2YXpYb0fIMgYLA5IYzSp0hLr7iU+2k9lritvkDpZw4qyydl7nt9SI/uSg4QIOsbHYOjis3tm7rhf5swbzdLzQ== Received: from AS9PR06CA0196.eurprd06.prod.outlook.com (2603:10a6:20b:45d::22) by PAWPR07MB9663.eurprd07.prod.outlook.com (2603:10a6:102:383::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.32; Sat, 2 Mar 2024 14:02:14 +0000 Received: from AM4PEPF00027A5E.eurprd04.prod.outlook.com (2603:10a6:20b:45d:cafe::1f) by AS9PR06CA0196.outlook.office365.com (2603:10a6:20b:45d::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.35 via Frontend Transport; Sat, 2 Mar 2024 14:02:13 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 192.176.1.74) smtp.mailfrom=ericsson.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=ericsson.com; Received-SPF: Pass (protection.outlook.com: domain of ericsson.com designates 192.176.1.74 as permitted sender) receiver=protection.outlook.com; client-ip=192.176.1.74; helo=oa.msg.ericsson.com; pr=C Received: from oa.msg.ericsson.com (192.176.1.74) by AM4PEPF00027A5E.mail.protection.outlook.com (10.167.16.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.11 via Frontend Transport; Sat, 2 Mar 2024 14:02:13 +0000 Received: from seliicinfr00050.seli.gic.ericsson.se (153.88.142.248) by smtp-central.internal.ericsson.com (100.87.178.69) with Microsoft SMTP Server id 15.2.1258.12; Sat, 2 Mar 2024 15:02:12 +0100 Received: from breslau.. (seliicwb00002.seli.gic.ericsson.se [10.156.25.100]) by seliicinfr00050.seli.gic.ericsson.se (Postfix) with ESMTP id CFE471C006A; Sat, 2 Mar 2024 15:02:12 +0100 (CET) From: =?utf-8?q?Mattias_R=C3=B6nnblom?= To: CC: , Heng Wang , =?utf-8?q?M?= =?utf-8?q?attias_R=C3=B6nnblom?= Subject: [RFC 0/7] Improve EAL bit operations API Date: Sat, 2 Mar 2024 14:53:21 +0100 Message-ID: <20240302135328.531940-1-mattias.ronnblom@ericsson.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM4PEPF00027A5E:EE_|PAWPR07MB9663:EE_ X-MS-Office365-Filtering-Correlation-Id: 664b9f25-b449-4118-8476-08dc3ac15c83 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: uKUxUBM5uoT9EY6HWN46pM7Q/+9c+k9BHaIlxOA0MmknGprdLQX1U5wtsVE5/qdoKJUga+s+d3zt8pAwoc8Gcyf5EvMqd1ajjucz+vvUFPbwhhygzwBrGjCkZ2pbDEOLkIv1v7f4ZFLpqvbd0iHgo61V6QQ+v35Jm6HA2DR8IIVBhPzmwX02JaP3pTmM82/axRs0in/a1oXkny0Ft1eqHSzP4XDCGn9v2FplWY/lE99bRcMQucDrWnKdG7TfTaWkhNCAiqf5j8Bqrc3b0UdzZPUBJYqWe1jrENAw2jxGRCxsRHhNogiVgbJu++Kphq5GDOTY18LJj6AXK5chjGat7bwwD4suwOOmTD+I6/JtpQn/NNOu55Ap3/UsGpu82Ty/AJUq6Pv64qamq3lGiPR6y2ou2WEyF7xFfHLWJHalNtMgOib25aLEwhvK7AvO1WkxgZEcylRHoKRR4+m+o9xkfYJCh0BQdewAelTqfVEImSe/Nfab5AT5hF8VoDy9PE1FRAfb0hPuZdQrydo9PZCxzu3CX8lyasSeFBr7eHRIbPVzWkKRNAZ2XAFZOvXmHfB01JFG9KCcv2N3IGXHZ0NH2M1F5v/TXcYNKLWQuMcZ287uAZ5KwYA/xUYcyRzbGLtCDpQzQIjIHJgS32VZKaC+Tdcwl4ijV1TE0jidz485vG8qkjdKefn1OX0lcyo8Q85hX+LCVXVRzei5ine5CuKjPJ7OVrU7jXyjblIZgFgU0URCFGSBZAQ5LgDpXVeVImWY X-Forefront-Antispam-Report: CIP:192.176.1.74; CTRY:SE; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:oa.msg.ericsson.com; PTR:office365.se.ericsson.net; CAT:NONE; SFS:(13230031)(376005)(36860700004)(82310400014); DIR:OUT; SFP:1101; X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Mar 2024 14:02:13.4364 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 664b9f25-b449-4118-8476-08dc3ac15c83 X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=92e84ceb-fbfd-47ab-be52-080c6b87953f; Ip=[192.176.1.74]; Helo=[oa.msg.ericsson.com] X-MS-Exchange-CrossTenant-AuthSource: AM4PEPF00027A5E.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR07MB9663 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 This patch set represent an attempt to improve and extend the RTE bitops API, in particular for functions that operate on individual bits. RFCv1 is submitted primarily to 1) receive general feedback on if improvements in this area is worth working on, and 2) receive feedback on the API. No test cases are included in v1 and the various functions may well not do what they are intended to. The legacy rte_bit_relaxed_*() family of functions is replaced with three families: rte_bit_[test|set|clear|assign][32|64]() which provides no memory ordering or atomicity guarantees and no read-once or write-once semantics (e.g., no use of volatile), but does provide the best performance. The performance degradation resulting from the use of volatile (e.g., forcing loads and stores to actually occur and in the number specified) and atomic (e.g., LOCK instructions on x86) may be a significant. rte_bit_once_*() which guarantees program-level load and stores actually occurring (i.e., prevents certain optimizations). The primary use of these functions are in the context of memory mapped I/O. Feedback on the details (semantics, naming) here would be greatly appreciated, since the author is not much of a driver developer. rte_bit_atomic_*() which provides atomic bit-level operations, including the possibility to specifying memory ordering constraints (or the lack thereof). The atomic functions take non-_Atomic pointers, to be flexible, just like the GCC builtins and default . The issue with _Atomic APIs is that it may well be the case that the user wants to perform both non-atomic and atomic operations on the same word. Having _Atomic-marked addresses would complicate supporting atomic bit-level operations in the proposed bitset API (and potentially other APIs depending on RTE bitops for atomic bit-level ops). Either one needs two bitset variants, one _Atomic bitset and one non-atomic one, or the bitset code needs to cast the non-_Atomic pointer to an _Atomic one. Having a separate _Atomic bitset would be bloat and also prevent the user from both, in some situations, doing atomic operations against a bit set, while in other situations (e.g., at times when MT safety is not a concern) operating on the same words in a non-atomic manner. That said, all this is still unclear to the author and much depending on the future path of DPDK atomics. Unlike rte_bit_relaxed_*(), individual bits are represented by bool, not uint32_t or uint64_t. The author found the use of such large types confusing, and also failed to see any performance benefits. A set of functions rte_bit_*_assign*() are added, to assign a particular boolean value to a particular bit. All functions have properly documented semantics. All functions are available in uint32_t and uint64_t variants. In addition, for every function there is a generic selection variant which operates on both 32-bit and 64-bit words (depending on the pointer type). The use of C11 generic selection is the first in the DPDK code base. _Generic allow the user code to be a little more impact. Have a generic atomic test/set/clear/assign bit API also seems consistent with the "core" (word-size) atomics API, which is generic (both GCC builtins and are). The _Generic versions also may avoid having explicit unsigned long versions of all functions. If you have an unsigned long, it's safe to use the generic version (e.g., rte_set_bit()) and _Generic will pick the right function, provided long is either 32 or 64 bit on your platform (which it is on all DPDK-supported ABIs). The generic rte_bit_set() is a macro, and not a function, but nevertheless has been given a lower-case name. That's how C11 does it (for atomics, and other _Generic), and . Its address can't be taken, but it does not evaluate its parameters more than once. Things that are left out of this patch set, that may be included in future versions: * Have all functions returning a bit number have the same return type (i.e., unsigned int). * Harmonize naming of some GCC builtin wrappers (i.e., rte_fls_u32()). * Add __builtin_ffsll()/ffs() wrapper and potentially other wrappers for useful/used bit-level GCC builtins. * Eliminate the MSVC #ifdef-induced documentation duplication. * _Generic versions of things like rte_popcount32(). (?) ABI-breaking patches should probably go into a separate patch set (?). Mattias Rönnblom (7): eal: extend bit manipulation functions eal: add generic bit manipulation macros eal: add bit manipulation functions which read or write once eal: add generic once-type bit operations macros eal: add atomic bit operations eal: add generic atomic bit operations eal: deprecate relaxed family of bit operations lib/eal/include/rte_bitops.h | 1115 +++++++++++++++++++++++++++++++++- 1 file changed, 1113 insertions(+), 2 deletions(-)