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 AEE3443BCD; Sat, 2 Mar 2024 21:22:13 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 83D2E40284; Sat, 2 Mar 2024 21:22:13 +0100 (CET) Received: from mail-ot1-f48.google.com (mail-ot1-f48.google.com [209.85.210.48]) by mails.dpdk.org (Postfix) with ESMTP id EB14640271 for ; Sat, 2 Mar 2024 21:22:11 +0100 (CET) Received: by mail-ot1-f48.google.com with SMTP id 46e09a7af769-6e4b34f2455so1891992a34.2 for ; Sat, 02 Mar 2024 12:22:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709410931; x=1710015731; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=h5PiNTUejfPueClE8+pjsd4RgGATMJ5j/kfiaV6ejoY=; b=UrjIrL/XX/vc8Bqspnx3aALAaSCbldlvt87H+HG3gkQ4mkgXuBsO2zE4RE3DWMofhE SQDeL81BQC5O+/+0aGWdrWOrrTXka0DzMO5Kfp/Qtqwti/nhJkfborU2iyBaCUiAVaeZ W31E1sz0QSh4FsG8TwzRrqpAP0EgNEjCP//9L1AFtomnAtXlvn7b53zOXs9AQ9NwtbO/ xWrKU0axphBl8IqamYf64f+B7scvOAvWiqBCZQBb+BOvKFYbgZlBxb3Mv6sx6O2Lfe4F RxX2thWrusir0FcruguAUBr3IbmnifQvHx+tHPK2u+OX1U++tGiJBQNGVJ7QRK4flvmk otsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709410931; x=1710015731; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=h5PiNTUejfPueClE8+pjsd4RgGATMJ5j/kfiaV6ejoY=; b=gduRUVLkaIO/E6sFEGm2e8q7k2O8aVTitPfF/zHJ3lV/dAeXRHAMCXuA3+/CRwsezc KgTdaEeYz8ArvfVEf3Fj0uOZQwIMjUYObCSdvFiQxNyuuh+sda6DSnHrE0QrpO/4Tvdh h95/wTalEjeAcir5NLAXmgF56qUCoc0LGzi6IuBTLAfhW3no3eZJVMZh/t4tYiUn69DX yTW6xE6T0KAph273UEEsiIxK1cEhCpiVRxCkta2tX5ib6HuK9J59+w7roYmmJfb+0vQM mvw2XcFL0DaXeqmeMsNxJs9utp0J0EqzQKbvd5Au+kMD3rmGvQa9sEm/TMMHijWWSrSE SQvg== X-Forwarded-Encrypted: i=1; AJvYcCXX597/ltJe3nFlFuKIpMkHkYZxaKed+BR0AQRPr2I7Vcqp5Ly6qjg1tFola7ILm+ogSqc39xqu4lHvw+E= X-Gm-Message-State: AOJu0YzPfQ12oLCY3oHrDaqbm12mMZ2beIwBPA2FkeraRkzvAIWCCThv AMkYKdlpXE34fTxIv0tcGQPh97fqO4IQ0Gs4sOWYE3quqDy4nWix2ZBX4AwL5tIEFwOpqWymHFS m9EYXSIOwT6M6CXxUohBdRzKuzw8= X-Google-Smtp-Source: AGHT+IFiaAdBDSFKoPdOG0FRrP8epynv++dZYDvDRxhqst0aI/CtbJldjIgRzdyfhMMvjcgKh1kPYHMalkXRyGZbJHU= X-Received: by 2002:a05:6870:b4aa:b0:21e:5733:f6fa with SMTP id y42-20020a056870b4aa00b0021e5733f6famr5404696oap.54.1709410930806; Sat, 02 Mar 2024 12:22:10 -0800 (PST) MIME-Version: 1.0 References: <20240207153340.34146-1-aomeryamac@gmail.com> <4CC50196-1F8F-40E2-8280-261783FDCFC8@arm.com> <772E05E7-716C-4A41-8C75-7323D9D745BC@arm.com> <508D578D-7B2D-485A-A408-AB3513FBBBD5@arm.com> In-Reply-To: From: =?UTF-8?B?QWJkdWxsYWggw5ZtZXIgWWFtYcOn?= Date: Sat, 2 Mar 2024 23:22:00 +0300 Message-ID: Subject: Re: [PATCH] lib/hash,lib/rcu: feature hidden key count in hash To: Honnappa Nagarahalli Cc: "Medvedkin, Vladimir" , "dev@dpdk.org" , Yipeng Wang , Sameh Gobriel , Bruce Richardson , "thomas@monjalon.net" , nd Content-Type: multipart/alternative; boundary="0000000000004e55860612b33f64" 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 --0000000000004e55860612b33f64 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry for the late reply. I understood what you mean. I will create only the reclaim API for the hash library. Thanks for the explanation. On Wed, Feb 28, 2024 at 5:51=E2=80=AFPM Honnappa Nagarahalli < Honnappa.Nagarahalli@arm.com> wrote: > > > > On Feb 28, 2024, at 5:44=E2=80=AFAM, Abdullah =C3=96mer Yama=C3=A7 > wrote: > > > > While I was implementing the new API, I realized one issue, and it woul= d > be good to discuss it here. First of all rte_rcu_qsbr_dq_reclaim function > checks the state of the qsbr values. It means that all threads should > report the quiescent states. It conflicts with my aim. > > > > Let's think about below scenario: > > Eight threads use a hash table and periodically report their quiescent > states. One additional thread (main thread) periodically reports the hash > size. I implemented the reclaim function in that thread. I mean, the main > thread calls reclaim before the rte_hash_count. > > > > Here is the exceptional case that I couldn't retrieve the correct hash > size: > > Assume that 6 of 8 threads reported quiescent states and 2 of them are > still working on some process and haven't reported quiescent states yet. > The main thread calls reclaim functions every time, but elements in dq wi= ll > not be freed because 2 of the worker threads haven't reported their state= s > (especially if they are waiting for some packets). So, my first proposed > method is more suitable for this case. Any idea? > If 2 out of 8 threads have not reported their quiescent state then the > elements that have not been acknowledged by those 2 threads cannot be > reclaimed and cannot be allocated for further use. Using this you can > calculate the most accurate number of entries in the hash table available > for allocation. > > > > > On Thu, Feb 22, 2024 at 7:44=E2=80=AFPM Honnappa Nagarahalli < > Honnappa.Nagarahalli@arm.com> wrote: > > > > > > > On Feb 22, 2024, at 6:39=E2=80=AFAM, Abdullah =C3=96mer Yama=C3=A7 > wrote: > > > > > > As a final decision, I will add a new hash API that forces the > reclaim. Is it ok for everyone? > > Ack from my side > > > > > > > > On Thu, Feb 22, 2024 at 5:37=E2=80=AFAM Honnappa Nagarahalli < > Honnappa.Nagarahalli@arm.com> wrote: > > > > > > > > > > On Feb 21, 2024, at 3:51=E2=80=AFPM, Abdullah =C3=96mer Yama=C3=A7 = < > aomeryamac@gmail.com> wrote: > > > > > > > > > > > > > > > > On Wed, Feb 21, 2024 at 6:24=E2=80=AFAM Honnappa Nagarahalli < > Honnappa.Nagarahalli@arm.com> wrote: > > > > > > > > > > > > > On Feb 20, 2024, at 12:58=E2=80=AFPM, Abdullah =C3=96mer Yama=C3= =A7 < > aomeryamac@gmail.com> wrote: > > > > > > > > > > I appreciate that you gave me suggestions and comments. I will > make changes according to all your recommendations, but before that, I wa= nt > to make everyone's minds clear. Then, I will apply modifications. > > > > > > > > > > On Tue, Feb 20, 2024 at 2:35=E2=80=AFAM Honnappa Nagarahalli < > Honnappa.Nagarahalli@arm.com> wrote: > > > > > > > > > > > > > > > > On Feb 19, 2024, at 3:28=E2=80=AFPM, Abdullah =C3=96mer Yama=C3= =A7 < > aomeryamac@gmail.com> wrote: > > > > > > > > > > > > Hello, > > > > > > > > > > > > Let me explain a use case; > > > > > > > > > > > > I have a hash table whose key value is IP addresses, and data > (let's say the username of the IP) is related to the IP address. The key > point is matching these data with flows. Flows are dynamic, and this hash > table is dynamic, as well; both can change anytime. For example, when a > flow starts, we look up the hash table with the corresponding IP and > retrieve the username. We need to hold this username until the flow > terminates, although we removed this IP key from the hash table > (multithread). That's why we have RCU and defer queue is necessary for hi= gh > performance. In my application, I need to know the number of IP-username > entries. These numbers can be calculated by rte_hash_count - defer queue > size. > > > > > The entries in the defer queue are not reclaimed (there is a > probability that all of them can be reclaimed) and hence they are not > available for allocation. So, rte_hash_count - defer queue size might not > give you the correct number you are expecting. > > > > > > > > > > Currently, there is no API in hash library that forces a reclaim. > Does it makes sense to have an API that just does the reclaim (and return= s > the number of entries pending in the defer queue)? A call to rte_hash_cou= nt > should provide the exact count you are looking for. > > > > > You are right; no API in the hash library forces a reclaim. In my > application, I periodically call rte_count to retrieve hash size, and thi= s > data is shown in my GUI. So that means I need to call regularly reclaim. = I > am trying to figure out which is better, calling reclaim or retrieving th= e > defer queue size. Any comment about this? > > > > Retrieving the defer queue size will be cheaper. However, calling > the reclaim API will ensure the entries are freed hence providing an > accurate number. Calling the reclaim API on an empty defer queue does not > consume many cycles. If needed we could add a check for empty defer queue > in the reclaim API and return early. > > > > > > > > I am also wondering if a reclaim API in hash library is needed. Why > not call rte_rcu_qsbr_dq_reclaim API from the application? > > > > The reason is simple. struct rte_hash *h is an internal structure > and we cannot access the h->dq. So it is not possible to call reclaim. > > > Ack. This will be just a wrapper around the rte_rcu_qsbr_dq_reclaim. > > > > > > > > > > > > > > > > > > > > > > > I think if you need a non-blocking and multithreaded hash table= , > an RCU-enabled hash table is necessary. Also, this API is necessary if yo= u > need to get the actual matchable size. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Feb 19, 2024 at 8:36=E2=80=AFPM Medvedkin, Vladimir < > vladimir.medvedkin@intel.com> wrote: > > > > > > Hi Abdullah, > > > > > > > > > > > > Could you please tell more about use cases where this API may b= e > useful? > > > > > > > > > > > > >a new API to get the hidden key count in the hash table if the > rcu qsbr is enabled > > > > > > > > > > > > Here in commit message and down below in doxygen comments, I > think this > > > > > > statement should be more specific because rcu can be created > with > > > > > > RTE_HASH_QSBR_MODE_SYNC mode i.e. without defer queue. > > > > > > > > > > > > Also, new API must be reflected in release notes > > > > > > > > > > > > On 07/02/2024 15:33, Abdullah =C3=96mer Yama=C3=A7 wrote: > > > > > > > This patch introduce a new API to get the hidden key count in > the hash > > > > > > > table if the rcu qsbr is enabled. When using rte_hash_count > with rcu > > > > > > > qsbr enabled, it will return the number of elements that are > not in the > > > > > > > free queue. Unless rte_rcu_qsbr_dq_reclaim is called, the > number of > > > > > > > elements in the defer queue will not be counted and freed. > Therefore I > > > > > > > added a new API to get the number of hidden (defer queue) > elements > > > > > > > in the hash table. Then the user can calculate the total > number of > > > > > > > elements that are available in the hash table. > > > > > > > > > > > > > > Signed-off-by: Abdullah =C3=96mer Yama=C3=A7 > > > > > > > > > > > > > > --- > > > > > > > Cc: Honnappa Nagarahalli > > > > > > > Cc: Yipeng Wang > > > > > > > Cc: Sameh Gobriel > > > > > > > Cc: Bruce Richardson > > > > > > > Cc: Vladimir Medvedkin > > > > > > > --- > > > > > > > lib/hash/rte_cuckoo_hash.c | 9 +++++++++ > > > > > > > lib/hash/rte_hash.h | 13 +++++++++++++ > > > > > > > lib/hash/version.map | 1 + > > > > > > > lib/rcu/rte_rcu_qsbr.c | 8 ++++++++ > > > > > > > lib/rcu/rte_rcu_qsbr.h | 11 +++++++++++ > > > > > > > lib/rcu/version.map | 1 + > > > > > > > 6 files changed, 43 insertions(+) > > > > > > > > > > > > > > diff --git a/lib/hash/rte_cuckoo_hash.c > b/lib/hash/rte_cuckoo_hash.c > > > > > > > index 70456754c4..3553f3efc7 100644 > > > > > > > --- a/lib/hash/rte_cuckoo_hash.c > > > > > > > +++ b/lib/hash/rte_cuckoo_hash.c > > > > > > > @@ -555,6 +555,15 @@ rte_hash_max_key_id(const struct rte_has= h > *h) > > > > > > > return h->entries; > > > > > > > } > > > > > > > > > > > > > > +int32_t > > > > > > > +rte_hash_dq_count(const struct rte_hash *h) > > > > > > > +{ > > > > > > > + if (h->dq =3D=3D NULL) > > > > > > input arguments must be checked since this is a public API, the > same is > > > > > > true for rte_rcu_qsbr_dq_count() > > > > > > > + return -EINVAL; > > > > > > why not just return 0? > > > > > > > + > > > > > > > + return rte_rcu_qsbr_dq_count(h->dq); > > > > > > > +} > > > > > > > + > > > > > > > int32_t > > > > > > > rte_hash_count(const struct rte_hash *h) > > > > > > > { > > > > > > > diff --git a/lib/hash/rte_hash.h b/lib/hash/rte_hash.h > > > > > > > index 7ecc021111..8ea97e297d 100644 > > > > > > > --- a/lib/hash/rte_hash.h > > > > > > > +++ b/lib/hash/rte_hash.h > > > > > > > @@ -193,6 +193,19 @@ rte_hash_free(struct rte_hash *h); > > > > > > > void > > > > > > > rte_hash_reset(struct rte_hash *h); > > > > > > > > > > > > > > + > > > > > > > +/** > > > > > > > + * Return the number of records in the defer queue of the > hash table > > > > > > > + * if RCU is enabled. > > > > > > > + * @param h > > > > > > > + * Hash table to query from > > > > > > > + * @return > > > > > > > + * - -EINVAL if parameters are invalid > > > > > > > + * - A value indicating how many records were inserted in > the table. > > > > > > did you mean how many records are kept in defer queue? > > > > > > > + */ > > > > > > > +int32_t > > > > > > > +rte_hash_dq_count(const struct rte_hash *h); > > > > > > > + > > > > > > > /** > > > > > > > * Return the number of keys in the hash table > > > > > > > * @param h > > > > > > > diff --git a/lib/hash/version.map b/lib/hash/version.map > > > > > > > index 6b2afebf6b..7f7b158cf1 100644 > > > > > > > --- a/lib/hash/version.map > > > > > > > +++ b/lib/hash/version.map > > > > > > > @@ -9,6 +9,7 @@ DPDK_24 { > > > > > > > rte_hash_add_key_with_hash; > > > > > > > rte_hash_add_key_with_hash_data; > > > > > > > rte_hash_count; > > > > > > > + rte_hash_dq_count; > > > > > > new API must introduced as an experimental API. The same is tru= e > for > > > > > > rte_rcu_qsbr_dq_count() > > > > > > > rte_hash_crc32_alg; > > > > > > > rte_hash_crc_set_alg; > > > > > > > rte_hash_create; > > > > > > > diff --git a/lib/rcu/rte_rcu_qsbr.c b/lib/rcu/rte_rcu_qsbr.c > > > > > > > index bd0b83be0c..89f8da4c4c 100644 > > > > > > > --- a/lib/rcu/rte_rcu_qsbr.c > > > > > > > +++ b/lib/rcu/rte_rcu_qsbr.c > > > > > > > @@ -450,6 +450,14 @@ rte_rcu_qsbr_dq_reclaim(struct > rte_rcu_qsbr_dq *dq, unsigned int n, > > > > > > > return 0; > > > > > > > } > > > > > > > > > > > > > > +/** > > > > > > > + * Return the number of entries in a defer queue. > > > > > > > + */ > > > > > > > +unsigned int rte_rcu_qsbr_dq_count(struct rte_rcu_qsbr_dq *d= q) > > > > > > > +{ > > > > > Please validate dq here. > > > > > > > > > > > > + return rte_ring_count(dq->r); > > > > > > > +} > > > > > > > + > > > > > > > /* Delete a defer queue. */ > > > > > > > int > > > > > > > rte_rcu_qsbr_dq_delete(struct rte_rcu_qsbr_dq *dq) > > > > > > > diff --git a/lib/rcu/rte_rcu_qsbr.h b/lib/rcu/rte_rcu_qsbr.h > > > > > > > index 23c9f89805..ed5a590edd 100644 > > > > > > > --- a/lib/rcu/rte_rcu_qsbr.h > > > > > > > +++ b/lib/rcu/rte_rcu_qsbr.h > > > > > > > @@ -794,6 +794,17 @@ int > > > > > > > rte_rcu_qsbr_dq_reclaim(struct rte_rcu_qsbr_dq *dq, unsigne= d > int n, > > > > > > > unsigned int *freed, unsigned int *pending, unsigned in= t > *available); > > > > > > > > > > > > > > +/** > > > > > > > + * Return the number of entries in a defer queue. > > > > > > > + * > > > > > > > + * @param dq > > > > > > > + * Defer queue. > > > > > > > + * @return > > > > > > > + * The number of entries in the defer queue. > > > > > > > + */ > > > > > > > +unsigned int > > > > > > > +rte_rcu_qsbr_dq_count(struct rte_rcu_qsbr_dq *dq); > > > > > Agree on the need for this API in RCU > > > > > > > > > > > > + > > > > > > > /** > > > > > > > * Delete a defer queue. > > > > > > > * > > > > > > > diff --git a/lib/rcu/version.map b/lib/rcu/version.map > > > > > > > index 982ffd59d9..f410ab41e7 100644 > > > > > > > --- a/lib/rcu/version.map > > > > > > > +++ b/lib/rcu/version.map > > > > > > > @@ -5,6 +5,7 @@ DPDK_24 { > > > > > > > rte_rcu_qsbr_dq_create; > > > > > > > rte_rcu_qsbr_dq_delete; > > > > > > > rte_rcu_qsbr_dq_enqueue; > > > > > > > + rte_rcu_qsbr_dq_count; > > > > > > > rte_rcu_qsbr_dq_reclaim; > > > > > > > rte_rcu_qsbr_dump; > > > > > > > rte_rcu_qsbr_get_memsize; > > > > > > > > > > > > -- > > > > > > Regards, > > > > > > Vladimir > > > > > > > > > > > > > > > > > > > > > > --0000000000004e55860612b33f64 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry for the late reply. I=C2=A0understood what you mean.= I will create only the reclaim API for the hash library. Thanks for the ex= planation.

On Wed, Feb 28, 2024 at 5:51=E2=80=AFPM Honnappa Nagarahalli <= Honnappa.Nagarahalli@arm.co= m> wrote:


> On Feb 28, 2024, at 5:44=E2=80=AFAM, Abdullah =C3=96mer Yama=C3=A7 <= ;aomeryamac@gmail= .com> wrote:
>
> While I was implementing the new API, I realized one issue, and it wou= ld be good to discuss it here. First of all rte_rcu_qsbr_dq_reclaim functio= n checks the state of the qsbr values. It means that all threads should rep= ort the quiescent states. It conflicts with my aim.
>
> Let's think about below scenario:
> Eight threads use a hash table and periodically report their quiescent= states. One additional thread (main thread) periodically reports the hash = size. I implemented the reclaim function in that thread. I mean, the main t= hread calls reclaim before the rte_hash_count.
>
> Here is the exceptional case that I couldn't retrieve the correct = hash size:
> Assume that 6 of 8 threads reported quiescent states and 2 of them are= still working on some process and haven't reported quiescent states ye= t. The main thread calls reclaim functions every time, but elements in dq w= ill not be freed because 2 of the worker threads haven't reported their= states (especially if they are waiting for some packets). So, my first pro= posed method is more suitable for this case. Any idea?
If 2 out of 8 threads have not reported their quiescent state then the elem= ents that have not been acknowledged by those 2 threads cannot be reclaimed= and cannot be allocated for further use. Using this you can calculate the = most accurate number of entries in the hash table available for allocation.=

>
> On Thu, Feb 22, 2024 at 7:44=E2=80=AFPM Honnappa Nagarahalli <Honnappa.Nagar= ahalli@arm.com> wrote:
>
>
> > On Feb 22, 2024, at 6:39=E2=80=AFAM, Abdullah =C3=96mer Yama=C3= =A7 <aomeryama= c@gmail.com> wrote:
> >
> > As a final decision, I will add a new hash API that forces the re= claim. Is it ok for everyone?
> Ack from my side
>
> >
> > On Thu, Feb 22, 2024 at 5:37=E2=80=AFAM Honnappa Nagarahalli <= Honnappa.= Nagarahalli@arm.com> wrote:
> >
> >
> > > On Feb 21, 2024, at 3:51=E2=80=AFPM, Abdullah =C3=96mer Yama= =C3=A7 <aomery= amac@gmail.com> wrote:
> > >
> > >
> > >
> > > On Wed, Feb 21, 2024 at 6:24=E2=80=AFAM Honnappa Nagarahalli= <Honn= appa.Nagarahalli@arm.com> wrote:
> > >
> > >
> > > > On Feb 20, 2024, at 12:58=E2=80=AFPM, Abdullah =C3=96me= r Yama=C3=A7 <= aomeryamac@gmail.com> wrote:
> > > >
> > > > I appreciate that you gave me suggestions and comments.= I will make changes according to all your recommendations, but before that= , I want to make everyone's minds clear. Then, I will apply modificatio= ns.
> > > >
> > > > On Tue, Feb 20, 2024 at 2:35=E2=80=AFAM Honnappa Nagara= halli <Honnappa.Nagarahalli@arm.com> wrote:
> > > >
> > > >
> > > > > On Feb 19, 2024, at 3:28=E2=80=AFPM, Abdullah =C3= =96mer Yama=C3=A7 <aomeryamac@gmail.com> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > Let me explain a use case;
> > > > >
> > > > > I have a hash table whose key value is IP addresse= s, and data (let's say the username of the IP) is related to the IP add= ress. The key point is matching these data with flows. Flows are dynamic, a= nd this hash table is dynamic, as well; both can change anytime. For exampl= e, when a flow starts, we look up the hash table with the corresponding IP = and retrieve the username. We need to hold this username until the flow ter= minates, although we removed this IP key from the hash table (multithread).= That's why we have RCU and defer queue is necessary for high performan= ce. In my application, I need to know the number of IP-username entries. Th= ese numbers can be calculated by rte_hash_count - defer queue size.
> > > > The entries in the defer queue are not reclaimed (there= is a probability that all of them can be reclaimed) and hence they are not= available for allocation. So, rte_hash_count - defer queue size might not = give you the correct number you are expecting.
> > > >
> > > > Currently, there is no API in hash library that forces = a reclaim. Does it makes sense to have an API that just does the reclaim (a= nd returns the number of entries pending in the defer queue)? A call to rte= _hash_count should provide the exact count you are looking for.
> > > > You are right; no API in the hash library forces a recl= aim. In my application, I periodically call rte_count to retrieve hash size= , and this data is shown in my GUI. So that means I need to call regularly = reclaim. I am trying to figure out which is better, calling reclaim or retr= ieving the defer queue size. Any comment about this?
> > > Retrieving the defer queue size will be cheaper. However, ca= lling the reclaim API will ensure the entries are freed hence providing an = accurate number. Calling the reclaim API on an empty defer queue does not c= onsume many cycles. If needed we could add a check for empty defer queue in= the reclaim API and return early.
> > >
> > > I am also wondering if a reclaim API in hash library is need= ed. Why not call rte_rcu_qsbr_dq_reclaim API from the application?
> > > The reason is simple. struct rte_hash *h is an internal stru= cture and we cannot access the h->dq. So it is not possible to call recl= aim.
> > Ack. This will be just a wrapper around the rte_rcu_qsbr_dq_recla= im.
> >
> > >
> > >
> > > > >
> > > > > I think if you need a non-blocking and multithread= ed hash table, an RCU-enabled hash table is necessary. Also, this API is ne= cessary if you need to get the actual matchable size.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Feb 19, 2024 at 8:36=E2=80=AFPM Medvedkin,= Vladimir <vladimir.medvedkin@intel.com> wrote:
> > > > > Hi Abdullah,
> > > > >
> > > > > Could you please tell more about use cases where t= his API may be useful?
> > > > >
> > > > > >a new API to get the hidden key count in the h= ash table if the rcu qsbr is enabled
> > > > >
> > > > > Here in commit message and down below in doxygen c= omments, I think this
> > > > > statement should be more specific because rcu can = be created with
> > > > > RTE_HASH_QSBR_MODE_SYNC mode i.e. without defer qu= eue.
> > > > >
> > > > > Also, new API must be reflected in release notes > > > > >
> > > > > On 07/02/2024 15:33, Abdullah =C3=96mer Yama=C3=A7= wrote:
> > > > > > This patch introduce a new API to get the hid= den key count in the hash
> > > > > > table if the rcu qsbr is enabled. When using = rte_hash_count with rcu
> > > > > > qsbr enabled, it will return the number of el= ements that are not in the
> > > > > > free queue. Unless rte_rcu_qsbr_dq_reclaim is= called, the number of
> > > > > > elements in the defer queue will not be count= ed and freed. Therefore I
> > > > > > added a new API to get the number of hidden (= defer queue) elements
> > > > > > in the hash table. Then the user can calculat= e the total number of
> > > > > > elements that are available in the hash table= .
> > > > > >
> > > > > > Signed-off-by: Abdullah =C3=96mer Yama=C3=A7 = <aomeryamac@gm= ail.com>
> > > > > >
> > > > > > ---
> > > > > > Cc: Honnappa Nagarahalli <honnappa.nagarahalli@arm.= com>
> > > > > > Cc: Yipeng Wang <yipeng1.wang@intel.com>
> > > > > > Cc: Sameh Gobriel <sameh.gobriel@intel.com>
> > > > > > Cc: Bruce Richardson <bruce.richardson@intel.com&= gt;
> > > > > > Cc: Vladimir Medvedkin <vladimir.medvedkin@intel.co= m>
> > > > > > ---
> > > > > >=C2=A0 =C2=A0lib/hash/rte_cuckoo_hash.c |=C2= =A0 9 +++++++++
> > > > > >=C2=A0 =C2=A0lib/hash/rte_hash.h=C2=A0 =C2=A0 = =C2=A0 =C2=A0 | 13 +++++++++++++
> > > > > >=C2=A0 =C2=A0lib/hash/version.map=C2=A0 =C2=A0= =C2=A0 =C2=A0|=C2=A0 1 +
> > > > > >=C2=A0 =C2=A0lib/rcu/rte_rcu_qsbr.c=C2=A0 =C2= =A0 =C2=A0|=C2=A0 8 ++++++++
> > > > > >=C2=A0 =C2=A0lib/rcu/rte_rcu_qsbr.h=C2=A0 =C2= =A0 =C2=A0| 11 +++++++++++
> > > > > >=C2=A0 =C2=A0lib/rcu/version.map=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 1 +
> > > > > >=C2=A0 =C2=A06 files changed, 43 insertions(+)=
> > > > > >
> > > > > > diff --git a/lib/hash/rte_cuckoo_hash.c b/lib= /hash/rte_cuckoo_hash.c
> > > > > > index 70456754c4..3553f3efc7 100644
> > > > > > --- a/lib/hash/rte_cuckoo_hash.c
> > > > > > +++ b/lib/hash/rte_cuckoo_hash.c
> > > > > > @@ -555,6 +555,15 @@ rte_hash_max_key_id(cons= t struct rte_hash *h)
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0return h->entries;
> > > > > >=C2=A0 =C2=A0}
> > > > > >=C2=A0 =C2=A0
> > > > > > +int32_t
> > > > > > +rte_hash_dq_count(const struct rte_hash *h)<= br> > > > > > > +{
> > > > > > +=C2=A0 =C2=A0 =C2=A0if (h->dq =3D=3D NULL= )
> > > > > input arguments must be checked since this is a pu= blic API, the same is
> > > > > true for rte_rcu_qsbr_dq_count()
> > > > > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0return -EINVAL;
> > > > > why not just return 0?
> > > > > > +
> > > > > > +=C2=A0 =C2=A0 =C2=A0return rte_rcu_qsbr_dq_c= ount(h->dq);
> > > > > > +}
> > > > > > +
> > > > > >=C2=A0 =C2=A0int32_t
> > > > > >=C2=A0 =C2=A0rte_hash_count(const struct rte_h= ash *h)
> > > > > >=C2=A0 =C2=A0{
> > > > > > diff --git a/lib/hash/rte_hash.h b/lib/hash/r= te_hash.h
> > > > > > index 7ecc021111..8ea97e297d 100644
> > > > > > --- a/lib/hash/rte_hash.h
> > > > > > +++ b/lib/hash/rte_hash.h
> > > > > > @@ -193,6 +193,19 @@ rte_hash_free(struct rte= _hash *h);
> > > > > >=C2=A0 =C2=A0void
> > > > > >=C2=A0 =C2=A0rte_hash_reset(struct rte_hash *h= );
> > > > > >=C2=A0 =C2=A0
> > > > > > +
> > > > > > +/**
> > > > > > + * Return the number of records in the defer= queue of the hash table
> > > > > > + * if RCU is enabled.
> > > > > > + * @param h
> > > > > > + *=C2=A0 Hash table to query from
> > > > > > + * @return
> > > > > > + *=C2=A0 =C2=A0- -EINVAL if parameters are i= nvalid
> > > > > > + *=C2=A0 =C2=A0- A value indicating how many= records were inserted in the table.
> > > > > did you mean how many records are kept in defer qu= eue?
> > > > > > + */
> > > > > > +int32_t
> > > > > > +rte_hash_dq_count(const struct rte_hash *h);=
> > > > > > +
> > > > > >=C2=A0 =C2=A0/**
> > > > > >=C2=A0 =C2=A0 * Return the number of keys in t= he hash table
> > > > > >=C2=A0 =C2=A0 * @param h
> > > > > > diff --git a/lib/hash/version.map b/lib/hash/= version.map
> > > > > > index 6b2afebf6b..7f7b158cf1 100644
> > > > > > --- a/lib/hash/version.map
> > > > > > +++ b/lib/hash/version.map
> > > > > > @@ -9,6 +9,7 @@ DPDK_24 {
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0rte_hash_add_key_wi= th_hash;
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0rte_hash_add_key_wi= th_hash_data;
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0rte_hash_count;
> > > > > > +=C2=A0 =C2=A0 =C2=A0rte_hash_dq_count;
> > > > > new API must introduced as an experimental API. Th= e same is true for
> > > > > rte_rcu_qsbr_dq_count()
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0rte_hash_crc32_alg;=
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0rte_hash_crc_set_al= g;
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0rte_hash_create; > > > > > > diff --git a/lib/rcu/rte_rcu_qsbr.c b/lib/rcu= /rte_rcu_qsbr.c
> > > > > > index bd0b83be0c..89f8da4c4c 100644
> > > > > > --- a/lib/rcu/rte_rcu_qsbr.c
> > > > > > +++ b/lib/rcu/rte_rcu_qsbr.c
> > > > > > @@ -450,6 +450,14 @@ rte_rcu_qsbr_dq_reclaim(= struct rte_rcu_qsbr_dq *dq, unsigned int n,
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0return 0;
> > > > > >=C2=A0 =C2=A0}
> > > > > >=C2=A0 =C2=A0
> > > > > > +/**
> > > > > > + * Return the number of entries in a defer q= ueue.
> > > > > > + */
> > > > > > +unsigned int rte_rcu_qsbr_dq_count(struct rt= e_rcu_qsbr_dq *dq)
> > > > > > +{
> > > > Please validate dq here.
> > > >
> > > > > > +=C2=A0 =C2=A0 =C2=A0return rte_ring_count(dq= ->r);
> > > > > > +}
> > > > > > +
> > > > > >=C2=A0 =C2=A0/* Delete a defer queue. */
> > > > > >=C2=A0 =C2=A0int
> > > > > >=C2=A0 =C2=A0rte_rcu_qsbr_dq_delete(struct rte= _rcu_qsbr_dq *dq)
> > > > > > diff --git a/lib/rcu/rte_rcu_qsbr.h b/lib/rcu= /rte_rcu_qsbr.h
> > > > > > index 23c9f89805..ed5a590edd 100644
> > > > > > --- a/lib/rcu/rte_rcu_qsbr.h
> > > > > > +++ b/lib/rcu/rte_rcu_qsbr.h
> > > > > > @@ -794,6 +794,17 @@ int
> > > > > >=C2=A0 =C2=A0rte_rcu_qsbr_dq_reclaim(struct rt= e_rcu_qsbr_dq *dq, unsigned int n,
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0unsigned int *freed= , unsigned int *pending, unsigned int *available);
> > > > > >=C2=A0 =C2=A0
> > > > > > +/**
> > > > > > + * Return the number of entries in a defer q= ueue.
> > > > > > + *
> > > > > > + * @param dq
> > > > > > + *=C2=A0 =C2=A0Defer queue.
> > > > > > + * @return
> > > > > > + *=C2=A0 =C2=A0The number of entries in the = defer queue.
> > > > > > + */
> > > > > > +unsigned int
> > > > > > +rte_rcu_qsbr_dq_count(struct rte_rcu_qsbr_dq= *dq);
> > > > Agree on the need for this API in RCU
> > > >
> > > > > > +
> > > > > >=C2=A0 =C2=A0/**
> > > > > >=C2=A0 =C2=A0 * Delete a defer queue.
> > > > > >=C2=A0 =C2=A0 *
> > > > > > diff --git a/lib/rcu/version.map b/lib/rcu/ve= rsion.map
> > > > > > index 982ffd59d9..f410ab41e7 100644
> > > > > > --- a/lib/rcu/version.map
> > > > > > +++ b/lib/rcu/version.map
> > > > > > @@ -5,6 +5,7 @@ DPDK_24 {
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0rte_rcu_qsbr_dq_cre= ate;
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0rte_rcu_qsbr_dq_del= ete;
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0rte_rcu_qsbr_dq_enq= ueue;
> > > > > > +=C2=A0 =C2=A0 =C2=A0rte_rcu_qsbr_dq_count; > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0rte_rcu_qsbr_dq_rec= laim;
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0rte_rcu_qsbr_dump;<= br> > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0rte_rcu_qsbr_get_me= msize;
> > > > >
> > > > > --
> > > > > Regards,
> > > > > Vladimir
> > > > >
> > > >
> > >
> >
>

--0000000000004e55860612b33f64--