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 3D10AA0C57; Thu, 4 Nov 2021 17:49:58 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1EEB141223; Thu, 4 Nov 2021 17:49:58 +0100 (CET) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by mails.dpdk.org (Postfix) with ESMTP id B3AFE411C9; Thu, 4 Nov 2021 17:49:56 +0100 (CET) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id A8BDC3201A3C; Thu, 4 Nov 2021 12:49:54 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Thu, 04 Nov 2021 12:49:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= KG8aUCDdxmDD8QYorpjpPs0sI0YcExRfm3LEz16342E=; b=JbjwG7n+zam+/bAS IsoHP+oWIcp8/QT/pmZHgvIRTHWZ+fA4J/yec4vqiuE1jklzCuDjHtOlBCUtQt5O lfcPovNSX1gOfruVxyEJJANp0N3Sf0lLzkMoEFo7bYuM/SHLwtJp5AFMTehRYkiw Wu1oY9RQfzAE5L/8hoC/eOwKn73lez0uRb68O4uDE2ZGs8rhWg4XbtHpepB6So5O fZiWsuIxoCvzbqOLyS3HcircEcUU9mmhIpSW48PomiW7/66SiRws3yF4YEsll0ka p+vjvMXciwupL9eiPKuebaUUvewxGuW4wVcsBr7aeHeqUMbdcLoyleK9LqMNUHRD 7f5Bmg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=KG8aUCDdxmDD8QYorpjpPs0sI0YcExRfm3LEz1634 2E=; b=Nco2M0RUfgxtYeAdB/rSwU8lO7V3tS7EcqKIqisjX6AapdyKbZbArPJJX ZD0Gr0UxpxSvR58naWL/Qppm8rqiN8qz3BirnGzXvULW/m8DSqSOrcF89Q82omoq gXZc5ZfYtI8zTf18AjnkbBcbUXguPXu+drR8H80cFI0az4AiNR8Tx1fjugyT10jB IgaZoCxi527/x4sMKkVPGY4vkmNwSvy/k+ZC0AYtvM+3EkVUkvfUN6fwoezM2qEZ yt2UJNtwz5RYRmCWrSCs0K6MI3yhjo4ajx5wlfMCnuQvHzJtBcz5TCsjZ82jjXQa gVsf3j8a0ityV1k6KX3s34qrwEIVQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrtdeggdeklecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 4 Nov 2021 12:49:52 -0400 (EDT) From: Thomas Monjalon To: "Medvedkin, Vladimir" Cc: "Kinsella, Ray" , Syam Prasad N Pearson , "users@dpdk.org" , "dev@dpdk.org" , "Wang, Yipeng1" , "Gobriel, Sameh" , "Richardson, Bruce" Date: Thu, 04 Nov 2021 17:49:51 +0100 Message-ID: <3060108.LiUVKm96O0@thomas> In-Reply-To: <6c1c908e-6a9a-c50d-0fa3-be61770ef97c@intel.com> References: <6c1c908e-6a9a-c50d-0fa3-be61770ef97c@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] Doubt regarding DPDK hash Library implementation 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 Sender: "dev" 04/11/2021 17:39, Medvedkin, Vladimir: > >> 01/11/2021 11:55, Syam Prasad N Pearson: > >>> /** Number of items per bucket. */ > >>> *#define RTE_HASH_BUCKET_ENTRIES 8* > >>> > >>> defined inside: > >>> dpdk-20.11.3/dpdk-stable-20.11.3/lib/librte_hash /rte_cuckoo_hash.h > >>> > >>> Why does the library take this value as *8*, is there any particular > >>> reason for this? what if it is 16,32... etc. > > Yes, RTE_HASH_BUCKET_ENTRIES can be any power of 2. > The reason for choosing 8 is a tradeoff between performance and memory. > When it is equal to 8, the sizeof(struct rte_hash_bucket) equal to > RTE_CACHE_LINE_SIZE, thus, there are no gaps in memory between the hash > buckets due to their alignment. That's a good comment to add in the code.