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 976D843A21; Wed, 31 Jan 2024 17:06:46 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7654B402C5; Wed, 31 Jan 2024 17:06:46 +0100 (CET) Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) by mails.dpdk.org (Postfix) with ESMTP id A3EE04026B for ; Wed, 31 Jan 2024 17:06:45 +0100 (CET) Received: by mail-pl1-f178.google.com with SMTP id d9443c01a7336-1d73066880eso42563365ad.3 for ; Wed, 31 Jan 2024 08:06:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1706717205; x=1707322005; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=2PKTcRiZmbfQgNGxvALMMzrwH8y7FHgzpSg4ml6kfLs=; b=UsOJbwLnSUVIFBIST4fl493iuDY6eZ006NxsHTzqr/4HKGHE7rS14S7Tch+AdfmcVg AyQpmTD22jrzWF29yQ14zHsg6SikoI7Yl2CUwlyxUFAtUUQn8WIb2KYozKl3ckKBsf2/ qzERwFqYrFWW0LbndTxxqCXpkRMUhDpliRQzVNU19u9Cgjby1jS3HX+B3qkfhj8aDaIY jDsJXUDoRtCjdp2TYxjSNygerOxTKFkKhwBfGGEXqMutGhBuHZNjHe+ergN794NL/sBy A8zm036BmNh2HkfS4ElZ9yMROAp090mO7d4pJNOfG2SlR784iLT9LL+lg0fe8UbFzWtp SfUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706717205; x=1707322005; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2PKTcRiZmbfQgNGxvALMMzrwH8y7FHgzpSg4ml6kfLs=; b=ib0S2iWYg55/VDOuhGswpXG577YaL+Cm6du7u8BkdAHX/TLWKzbcIXaf16Nkg8FqqM 66sjjW0yQWqEGR4Zy2O2dkcKs8Tqgyno16RhbcBgwqTYGU9tsTK0Zg2ObkhEZUWvz7ad cYaKMyz7QPATDPmPybhWVUmkCUJo3c+bLTM6H5hzzlALTBqApnZUy24Y0Oc6Wqar0AfU i9HPHcau3qETOJBShhm+h0NgSMCJR8rz20eBXJjVNuJDjDRqF+cpNCFvnBWjk93lvNSL n2J4369J2hp88oRh6hDD/6C/RLFTEISxzrW8XV9ckyGSSKsxtNGKN1bpIb6QoqUIO+CP CPJQ== X-Gm-Message-State: AOJu0YwmwXA7iST58I/vviO/7OkvWihyu7FAUesyp9Zk7k/R+Ulpfvyd Yq/1RKKYcz8WaUEsUFL7TcM71PXoGbVK9//7yirlvEcAPiVSm6QNAEU+ebdEe8s= X-Google-Smtp-Source: AGHT+IEs8moKHSQhIM099UhfqO80vGGPiJXofb+kbbVQMJWqPD6r2c6ilX42jl/zCQI8LSP1ohh6aQ== X-Received: by 2002:a17:902:d2c5:b0:1d9:1ab6:fe87 with SMTP id n5-20020a170902d2c500b001d91ab6fe87mr2573021plc.29.1706717204811; Wed, 31 Jan 2024 08:06:44 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCUUR9dcieTNXeM8N5M3/AKIpcYM/fE9i/DVmebbdIV9NXjHXeEaRdy91NeK5G8J2iooCBLsobpKxJJUs7Mr01n90m48UxLMI9xHrElS72UNc3AyFn86trS5c7fxf/VQA3wb2Ju3ZpiOyQ6xYI+orJTQGHI2fP9AxeAuh5g5FA== Received: from hermes.local (204-195-123-141.wavecable.com. [204.195.123.141]) by smtp.gmail.com with ESMTPSA id x10-20020a170902ec8a00b001d8924d8dbfsm9196584plg.265.2024.01.31.08.06.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 31 Jan 2024 08:06:44 -0800 (PST) Date: Wed, 31 Jan 2024 08:06:43 -0800 From: Stephen Hemminger To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= Cc: , , Morten =?UTF-8?B?QnLDuHJ1cA==?= , Tyler Retzlaff Subject: Re: [RFC v3] eal: add bitset type Message-ID: <20240131080643.41a03cd8@hermes.local> In-Reply-To: <20240131131301.418361-1-mattias.ronnblom@ericsson.com> References: <20240131131301.418361-1-mattias.ronnblom@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 Wed, 31 Jan 2024 14:13:01 +0100 Mattias R=C3=B6nnblom wrote: > +/** > + * @file > + * RTE Bitset > + * > + * This file provides functions and macros for querying and > + * manipulating sets of bits kept in arrays of @c uint64_t-sized > + * elements. > + * > + * The bits in a bitset are numbered from 0 to @c size - 1, with the > + * lowest index being the least significant bit. > + * > + * The bitset array must be properly aligned. > + * > + * For optimal performance, the @c size parameter, required by > + * many of the API's functions, should be a compile-time constant. > + * > + * For large bitsets, the rte_bitmap.h API may be more appropriate. > + * > + * @warning > + * All functions modifying a bitset may overwrite any unused bits of > + * the last word. Such unused bits are ignored by all functions reading > + * bits. > + * > + */ FYI - the linux kernel has a similar but more complete set of operations. It might be more efficient to use unsigned long rather than requiring the elements to be uint64_t. Thinking of the few 32 bit platforms. Also, what if any thread safety guarantees? or atomic. =46rom kernel bitmap.h /** * DOC: bitmap overview * * The available bitmap operations and their rough meaning in the * case that the bitmap is a single unsigned long are thus: * * The generated code is more efficient when nbits is known at * compile-time and at most BITS_PER_LONG. * * :: * * bitmap_zero(dst, nbits) *dst =3D 0UL * bitmap_fill(dst, nbits) *dst =3D ~0UL * bitmap_copy(dst, src, nbits) *dst =3D *src * bitmap_and(dst, src1, src2, nbits) *dst =3D *src1 & *src2 * bitmap_or(dst, src1, src2, nbits) *dst =3D *src1 | *src2 * bitmap_xor(dst, src1, src2, nbits) *dst =3D *src1 ^ *src2 * bitmap_andnot(dst, src1, src2, nbits) *dst =3D *src1 & ~(*src2) * bitmap_complement(dst, src, nbits) *dst =3D ~(*src) * bitmap_equal(src1, src2, nbits) Are *src1 and *src2 equal? * bitmap_intersects(src1, src2, nbits) Do *src1 and *src2 overlap? * bitmap_subset(src1, src2, nbits) Is *src1 a subset of *src2? * bitmap_empty(src, nbits) Are all bits zero in *src? * bitmap_full(src, nbits) Are all bits set in *src? * bitmap_weight(src, nbits) Hamming Weight: number set = bits * bitmap_weight_and(src1, src2, nbits) Hamming Weight of and'ed bi= tmap * bitmap_set(dst, pos, nbits) Set specified bit area * bitmap_clear(dst, pos, nbits) Clear specified bit area * bitmap_find_next_zero_area(buf, len, pos, n, mask) Find bit free area * bitmap_find_next_zero_area_off(buf, len, pos, n, mask, mask_off) as ab= ove * bitmap_shift_right(dst, src, n, nbits) *dst =3D *src >> n * bitmap_shift_left(dst, src, n, nbits) *dst =3D *src << n * bitmap_cut(dst, src, first, n, nbits) Cut n bits from first, copy= rest * bitmap_replace(dst, old, new, mask, nbits) *dst =3D (*old & ~(*mask)) = | (*new & *mask) * bitmap_remap(dst, src, old, new, nbits) *dst =3D map(old, new)(src) * bitmap_bitremap(oldbit, old, new, nbits) newbit =3D map(old, new)(ol= dbit) * bitmap_onto(dst, orig, relmap, nbits) *dst =3D orig relative to r= elmap * bitmap_fold(dst, orig, sz, nbits) dst bits =3D orig bits mod = sz * bitmap_parse(buf, buflen, dst, nbits) Parse bitmap dst from kerne= l buf * bitmap_parse_user(ubuf, ulen, dst, nbits) Parse bitmap dst from user = buf * bitmap_parselist(buf, dst, nbits) Parse bitmap dst from kerne= l buf * bitmap_parselist_user(buf, dst, nbits) Parse bitmap dst from user = buf * bitmap_find_free_region(bitmap, bits, order) Find and allocate bit reg= ion * bitmap_release_region(bitmap, pos, order) Free specified bit region * bitmap_allocate_region(bitmap, pos, order) Allocate specified bit regi= on * bitmap_from_arr32(dst, buf, nbits) Copy nbits from u32[] buf t= o dst * bitmap_from_arr64(dst, buf, nbits) Copy nbits from u64[] buf t= o dst * bitmap_to_arr32(buf, src, nbits) Copy nbits from buf to u32[= ] dst * bitmap_to_arr64(buf, src, nbits) Copy nbits from buf to u64[= ] dst * bitmap_get_value8(map, start) Get 8bit value from map at = start * bitmap_set_value8(map, value, start) Set 8bit value to map at st= art * * Note, bitmap_zero() and bitmap_fill() operate over the region of * unsigned longs, that is, bits behind bitmap till the unsigned long * boundary will be zeroed or filled as well. Consider to use * bitmap_clear() or bitmap_set() to make explicit zeroing or filling * respectively. */