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 934C843C3F for ; Thu, 29 Feb 2024 19:04:16 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8292A42F83; Thu, 29 Feb 2024 19:04:16 +0100 (CET) Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com [209.85.167.174]) by mails.dpdk.org (Postfix) with ESMTP id EC192402B4 for ; Thu, 29 Feb 2024 11:41:45 +0100 (CET) Received: by mail-oi1-f174.google.com with SMTP id 5614622812f47-3c1a7d51fb5so608115b6e.1 for ; Thu, 29 Feb 2024 02:41:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709203305; x=1709808105; darn=dpdk.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=k2WTcEP0JSS6TuzNm/P9ghHvVx1IF9/BN/hGGGZLfSY=; b=M/RXLvyn+dyWBv6FTHuccK3pK1+S8UTD2idFjfsOI29vvGqvG9dNQ7nisZ2fU5ulXi 8OcJd/QtUfcl+r3YVUeYNBJOT+ZznjaH34NgdXfhk1ogSSVeM+O5Dlp1FXwePMZ6kek/ 7GGyggQeOsIhqL+P0aFo+r5vlb52w1IqESCqQWGUUx+hS/yMwQSASUe633itAM7ahTGe pCZ9GKlTaGqPGiZU5FAg4BCwcytt5rqSuX+4Yvqh+zy13wNvHOmGWLC1BfAQJh3u95+a 3wYVmP7bNeET/DH0JoGCm2xfzwmyQTb7Z9/tQvHYtgouFLxVEBbrtsmuOxCH0CTEoy+P aKCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709203305; x=1709808105; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=k2WTcEP0JSS6TuzNm/P9ghHvVx1IF9/BN/hGGGZLfSY=; b=pNNj5jh8Im3H3bpBfURK/L3ptgap7ialPL2u6BzXnCuUBDdbNMQ0EXKsZsPZgDkJWu dBO+Cgf/vr0kT5+0luS7vaPrOQhz86WagT7hVZKfPXpAyNb29ZyKHYDeTzWU7GCjSId7 zNciDzsVoGTrsVSph+cdZvKSqFm5tAjzYMVtdHGRW4LIU+SSN/ejUF4ycY0qkscNRboo oNrXIJNkoIxWZAxcUYgZ41tdgcYdod7YwfWKakSoHF+/Th6zkHJUETEBAPqDnBc7mUGd rb+2IEjTGGj8cjhtmneb+74C4VKKsRSiEn0nUecLz8MnVNjobWdvP0aAh2H+w26GqtKc +82Q== X-Gm-Message-State: AOJu0Yxxe+i6wCYcJFwxXmGky3A3Vp2/f/XQl4C3atGKtlBPshsOjtpd VtHUtgk4mshzHSMGQifTwfImU7aqbrafsqRSsOpDJhKopt6fOZat6trmrpggN9eKg12IiP9UzAW qaF0hGZkoYKZIy8gyzFo1iULP/33D4IBjnkQ8qQ== X-Google-Smtp-Source: AGHT+IGQVsjtInLDK82Q7HHLaureHbwfzbh8tokKymYTsmHJHXu63LzBd9bWB5ED57/D3wcxaL6MwNeMqswMTLRP914= X-Received: by 2002:a05:6870:c34a:b0:21f:c7fa:78f5 with SMTP id e10-20020a056870c34a00b0021fc7fa78f5mr1502957oak.7.1709203304807; Thu, 29 Feb 2024 02:41:44 -0800 (PST) MIME-Version: 1.0 From: Nadirbek Nurlybekov Date: Thu, 29 Feb 2024 16:41:33 +0600 Message-ID: Subject: rte_hash implementation details To: users@dpdk.org Content-Type: multipart/alternative; boundary="000000000000d50298061282e7b9" X-Mailman-Approved-At: Thu, 29 Feb 2024 19:04:15 +0100 X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org --000000000000d50298061282e7b9 Content-Type: text/plain; charset="UTF-8" Hello DPDK Users, I hope this email finds you all in good spirits. My name is Nadirbek, and I'm currently in the process of understanding the rte_hash table implementation. As I explore the codebase and its functionalities, I've encountered a question regarding a specific aspect of the rte_hash implementation. In particular, I'm examining the rte_hash_cuckoo_make_space_mw function, which is responsible for moving an entry to its secondary bucket to accommodate a new key. However, I've noticed a potential scenario where the same entry might be moved multiple times, leading to the situation where the lookup fails to locate the key in either the primary or secondary bucket. Upon reviewing the code, I observed that each bucket has a next pointer, but it seems to be primarily utilized in extendable buckets. This observation has prompted me to question whether my understanding of the implementation is correct or if there's a deliberate design choice behind this behavior. I kindly request your assistance in shedding light on this matter. Thank you all for your time and consideration. I eagerly await your responses and insights. Best regards, Nadirbek Nurlybekov nurlybekovnt@gmail.com --000000000000d50298061282e7b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello DPDK Users,

I hope this email finds you all i= n good spirits. My name is Nadirbek, and I'm currently in the process o= f understanding the rte_hash table implementation. As I explore the codebas= e and its functionalities, I've encountered a question regarding a spec= ific aspect of the rte_hash implementation.

In particular, I'm e= xamining the rte_hash_cuckoo_make_space_mw function, which is responsible f= or moving an entry to its secondary bucket to accommodate a new key. Howeve= r, I've noticed a potential scenario where the same entry might be move= d multiple times, leading to the situation where the lookup fails to locate= the key in either the primary or secondary bucket.

Upon reviewing t= he code, I observed that each bucket has a next pointer, but it seems to be= primarily utilized in extendable buckets. This observation has prompted me= to question whether my understanding of the implementation is correct or i= f there's a deliberate design choice behind this behavior.

I kin= dly request your assistance in shedding light on this matter. Thank you all= for your time and consideration. I eagerly await your responses and insigh= ts.

Best regards,
Nadirbek Nurlybekov
--000000000000d50298061282e7b9--