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 67B934233C; Mon, 9 Oct 2023 17:54:07 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3ED12406BA; Mon, 9 Oct 2023 17:54:07 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id F20F1402A3 for ; Mon, 9 Oct 2023 17:54:05 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id A0B0D5C0381; Mon, 9 Oct 2023 11:54:05 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Mon, 09 Oct 2023 11:54:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1696866845; x=1696953245; bh=AKYuE0igjtYnk9HkbyvdT6oJtNdSIMvCK0B HIH8cXd0=; b=IJJW+3Qncy6T5oIKIPEupZVp8mlTu4+WCo0ZYoxQhmoSSxNhwfC +gDeBSObINRfwlpZL7IoI6Xu64NlNV+Ws+3OTqC48gh5qlDaBim7B9B3M4aa/R24 AiaynyZoSpoLgg2BikAKK9YJhOhGAzB7OML8QEsk+Xdsk5LTh2ygFZpY3Rj/IToI bWMVsN2ynYO+wRqwe250Vqc0pcAd8d8xgh624XMXXdpQ9Gn86WsR/3dN72pruCvi keuDbPjRGdxmIVckQtwszO918vZo8faUFFtlR3kF17NT9M4VorKVQYoU7UzhneVv mbVFuIXDNdRKx3oBp+Q1JXT8g5hj7FxZ8Rg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1696866845; x=1696953245; bh=AKYuE0igjtYnk9HkbyvdT6oJtNdSIMvCK0B HIH8cXd0=; b=hK6zb2XSG0HUfJjZZ6WMi89VeVqFl7v0GMYCGyzIvEfG3pf9Jne 3RM1s7bNjw5ne4XXUPA5df/v3vAUXdLosLAMyELVksvm5sMl1ljxNLTvMCqEW1pD GMDDPVWSizG+MucyQUvInStAoD+yzW+S37zh8dprm/GRVVLUGf2s4kh7/8OQ0LAc Dk207Cg/fxoCUkGQaTjzM12DVKtwhzs4PyFU9RI5efqBI2kxOEy7sntQWz/ij6q+ J5PCsDBsJWY8IAl7XroNAfsQTkgC+PYPRutpCOIlMF4jzZrNBcQ2z9Qzk3K6AB2S eS/dzzdLWTBvTHKc0/pCisW9GVLb7ezXi5A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrheefgdelgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnheptdejieeifeehtdffgfdvleetueeffeehueejgfeuteeftddtieek gfekudehtdfgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 9 Oct 2023 11:54:04 -0400 (EDT) From: Thomas Monjalon To: Paul Szczepanek Cc: dev@dpdk.org, Honnappa Nagarahalli , Kamalakshitha Aligeri Subject: Re: [RFC 1/2] eal: add pointer compression functions Date: Mon, 09 Oct 2023 17:54:03 +0200 Message-ID: <22038988.EfDdHjke4D@thomas> In-Reply-To: <20230927150854.3670391-2-paul.szczepanek@arm.com> References: <20230927150854.3670391-1-paul.szczepanek@arm.com> <20230927150854.3670391-2-paul.szczepanek@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 27/09/2023 17:08, Paul Szczepanek: > Add a new utility header for compressing pointers. Pointers are > compressed by taking advantage of their locality. Instead of > storing the full address only an offset from a known base is stored. You probably need to insert some explanations from the cover letter. > The provided functions can store pointers in 32bit offsets. > > Suggested-by: Honnappa Nagarahalli > Signed-off-by: Paul Szczepanek > Signed-off-by: Kamalakshitha Aligeri > Reviewed-by: Honnappa Nagarahalli [...] > --- a/lib/eal/include/meson.build > +++ b/lib/eal/include/meson.build > @@ -35,6 +35,7 @@ headers += files( > 'rte_pci_dev_feature_defs.h', > 'rte_pci_dev_features.h', > 'rte_per_lcore.h', > + 'rte_ptr_compress.h', > 'rte_pflock.h', > 'rte_random.h', > 'rte_reciprocal.h', Did you try to sort alphabetically? failed :) > +#ifndef _RTE_PTR_COMPRESS_H_ > +#define _RTE_PTR_COMPRESS_H_ No need extra underscores. > + > +/** > + * @file > + * RTE pointer compression and decompression. RTE has no mean here I think. > + */ > + > +#include > +#include > + > +#include > +#include > +#include > +#include > + > +#ifdef __cplusplus > +extern "C" { > +#endif > + > +/** > + * Compress pointers into 32 bit offsets from base pointer. I think it should be "32-bit". > + * > + * @note Offsets from the base pointer must fit within 32bits. Alignment allows > + * us to drop bits from the offsets - this means that for pointers aligned by > + * 8 bytes they must be within 32GB of the base pointer. Unaligned pointers > + * must be within 4GB. Not clear what is "alignment". > + * > + * @param ptr_base > + * A pointer used to calculate offsets of pointers in src_table. > + * @param src_table > + * A pointer to an array of pointers. > + * @param dest_table > + * A pointer to an array of compressed pointers returned by this function. > + * @param n > + * The number of objects to compress, must be strictly positive. > + * @param bit_shift > + * Byte alignment of memory pointed to by the pointers allows for > + * bits to be dropped from the offset and hence widen the memory region that > + * can be covered. This controls how many bits are right shifted. > + **/ > +static __rte_always_inline void > +rte_ptr_compress_32(void *ptr_base, void **src_table, > + uint32_t *dest_table, unsigned int n, unsigned int bit_shift) > +{ > + unsigned int i = 0; > +#if defined RTE_HAS_SVE_ACLE > + svuint64_t v_src_table; > + svuint64_t v_dest_table; > + svbool_t pg = svwhilelt_b64(i, n); > + do { > + v_src_table = svld1_u64(pg, (uint64_t *)src_table + i); > + v_dest_table = svsub_x(pg, v_src_table, (uint64_t)ptr_base); > + v_dest_table = svlsr_x(pg, v_dest_table, bit_shift); > + svst1w(pg, &dest_table[i], v_dest_table); > + i += svcntd(); > + pg = svwhilelt_b64(i, n); > + } while (svptest_any(svptrue_b64(), pg)); > +#elif defined __ARM_NEON > + uint64_t ptr_diff; > + uint64x2_t v_src_table; > + uint64x2_t v_dest_table; > + /* right shift is done by left shifting by negative int */ > + int64x2_t v_shift = vdupq_n_s64(-bit_shift); > + uint64x2_t v_ptr_base = vdupq_n_u64((uint64_t)ptr_base); > + for (; i < (n & ~0x1); i += 2) { > + v_src_table = vld1q_u64((const uint64_t *)src_table + i); > + v_dest_table = vsubq_u64(v_src_table, v_ptr_base); > + v_dest_table = vshlq_u64(v_dest_table, v_shift); > + vst1_u32(dest_table + i, vqmovn_u64(v_dest_table)); > + } > + /* process leftover single item in case of odd number of n */ > + if (unlikely(n & 0x1)) { > + ptr_diff = RTE_PTR_DIFF(src_table[i], ptr_base); > + dest_table[i] = (uint32_t) (ptr_diff >> bit_shift); > + } > +#else > + uint64_t ptr_diff; > + for (; i < n; i++) { > + ptr_diff = RTE_PTR_DIFF(src_table[i], ptr_base); > + /* save extra bits that are redundant due to alignment */ > + ptr_diff = ptr_diff >> bit_shift; > + /* make sure no truncation will happen when casting */ > + RTE_ASSERT(ptr_diff <= UINT32_MAX); > + dest_table[i] = (uint32_t) ptr_diff; > + } > +#endif > +} I see it is providing some per-CPU optimizations, so it is in favor of having it in DPDK. Other than that, it looks very generic, so it is questionable to have in DPDK.