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 6407443C1E; Wed, 28 Feb 2024 12:44:56 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3C61D402AE; Wed, 28 Feb 2024 12:44:56 +0100 (CET) Received: from mail-oa1-f42.google.com (mail-oa1-f42.google.com [209.85.160.42]) by mails.dpdk.org (Postfix) with ESMTP id 5B58640295 for ; Wed, 28 Feb 2024 12:44:54 +0100 (CET) Received: by mail-oa1-f42.google.com with SMTP id 586e51a60fabf-2206232d806so515572fac.2 for ; Wed, 28 Feb 2024 03:44:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709120693; x=1709725493; 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=yPuZw7GfDPpxM0te6KEz5th9ZKYF68fiIKcArqojrL8=; b=lDKf2Dd05086xB+Nw2l+iKSyDv6nWc6gkPljNXoqHgkNTSoimjJqM54lyxGq99K9qy KX4vhXYgij5W6ngXDU0Z2nF1hWcP67KiKbTbjXra5LDz3drFfQX5aB9UJPz1icNZTUu+ S8kuARAKh8dBJeIlCXNWwZ/Lwvj9GV+/avgKQ9vTF0hNM6I3G0+aHPzsYeJtjqweoaCH stuhI69jLPuUEm/BuDgbZ5KCRd72AKU2v/NjNPIg5w0QrVLfm/GqTNYo3dBlNIvHV6MM gXRIC6oi8vbAzlQM3hLQu22rCPz48HzWQwLHRC4cJlC/V675F5OIv4cEzj033vrs3fKH dyuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709120693; x=1709725493; 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=yPuZw7GfDPpxM0te6KEz5th9ZKYF68fiIKcArqojrL8=; b=cB4Pev8V7yiv88/dR0N1W7YxopOEEYkN/jv4V1RB/wqI+h1+PKDh2Olh6ahsN3ABq7 Me6YM6haj/VXX0tiGJBvU/vFuYh56J0g0bbpibGmBSZ8m1MfpnVpTAH3p1E9WlOIAI0G LXyUoOUnK5gV2PhGPQDhboDBf9tmNEmjssgsnZ8fNR3s9tZS0WAdjNRnAWyjsBCT3sVj rv5kB7+evivTKrT3FHlMHxcmBa/abvoU4SUTK6wLui/neHMnIB6/tVMX7ujTdYp6kr73 v0AWyOjB2fIC//g5z4HAKy8/+PPoUlPTW7lgP/IpruQPFrNDrjnXULfw2DTQtIHZEGiI j6uQ== X-Forwarded-Encrypted: i=1; AJvYcCWmxwRrAbGTo8Z6bkvhghqOxPoP7gBe4oJvnljy+9O7MjSbCpoBB5UgULsYzT3RMXru6tjIwO0TQqGoAm8= X-Gm-Message-State: AOJu0YyYQ6s+0Vpg/zzC3Yx+nok8abeNeR8T+PFTyPcmKIFjXdslTXzY PSqo3RqfY+h0KF7Y5JcSLpiuXX4xWwCY+HezYoWrwm3NHfdtCHQnoxCn/lyLFEasb7CKwHKB3y0 Vat0A/BYri4IXPHG82vt2/GACCZc= X-Google-Smtp-Source: AGHT+IEDz9oxQM0zYJy+jQ8ecY6O9FEsRzcSS17sU44qEqLum378d8b/75hIcaOpfU1TZEV3K5Cex1wZ8hEK/vGIhEs= X-Received: by 2002:a05:6870:55cb:b0:21f:e244:e356 with SMTP id qk11-20020a05687055cb00b0021fe244e356mr10547863oac.2.1709120693458; Wed, 28 Feb 2024 03:44:53 -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: <508D578D-7B2D-485A-A408-AB3513FBBBD5@arm.com> From: =?UTF-8?B?QWJkdWxsYWggw5ZtZXIgWWFtYcOn?= Date: Wed, 28 Feb 2024 14:44:44 +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="000000000000cfdb4c06126fab40" 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 --000000000000cfdb4c06126fab40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable While I was implementing the new API, I realized one issue, and it would 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 will 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 proposed method is more suitable for this case. Any idea? 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 > 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 want 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 be > 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 thin= k > 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 wit= h > rcu > > > > > > qsbr enabled, it will return the number of elements that are no= t > in the > > > > > > free queue. Unless rte_rcu_qsbr_dq_reclaim is called, the numbe= r > 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_hash > *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 th= e > 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 true > 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 *dq) > > > > > > +{ > > > > 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, unsigned > int n, > > > > > > unsigned int *freed, unsigned int *pending, unsigned int > *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 > > > > > > > > > > > > > > > > --000000000000cfdb4c06126fab40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While I was implementing the new API, I realized one issue= , and it would be good to discuss it here. First of all=C2=A0rte_rcu_qsbr_d= q_reclaim function checks the state of the qsbr values. It means that all t= hreads should report the quiescent=C2=A0states. It conflicts with my aim.
Let's think about below scenario:
Eight threads use a hash tab= le and periodically report their quiescent states. One additional thread (m= ain thread)=C2=A0periodically=C2=A0reports the hash size. I implemented the= reclaim function in that thread. I mean, the main thread calls reclaim bef= ore the rte_hash_count.

Here is the exceptional case that I couldn&#= 39;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 functio= ns every time, but elements in dq will 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 proposed method is more suitable for this c= ase. Any idea?

On Thu, Feb 22, 2024 at 7:44=E2=80=AFPM Honnappa Nagaraha= lli <Honnappa.Nagarahall= i@arm.com> wrote:


> On Feb 22, 2024, at 6:39=E2=80=AFAM, Abdullah =C3=96mer Yama=C3=A7 <= ;aomeryamac@gmail= .com> 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.Nagar= ahalli@arm.com> wrote:
>
>
> > On Feb 21, 2024, at 3:51=E2=80=AFPM, Abdullah =C3=96mer Yama=C3= =A7 <aomeryama= c@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 Yam= a=C3=A7 <aomer= yamac@gmail.com> wrote:
> > >
> > > I appreciate that you gave me suggestions and comments. I wi= ll make changes according to all your recommendations, but before that, I w= ant to make everyone's minds clear. Then, I will apply modifications. <= br> > > >
> > > On Tue, Feb 20, 2024 at 2:35=E2=80=AFAM Honnappa Nagarahalli= <Honn= appa.Nagarahalli@arm.com> wrote:
> > >
> > >
> > > > On Feb 19, 2024, at 3:28=E2=80=AFPM, Abdullah =C3=96mer= Yama=C3=A7 <a= omeryamac@gmail.com> wrote:
> > > >
> > > > Hello,
> > > >
> > > > Let me explain a use case;
> > > >
> > > > I have a hash table whose key value is IP addresses, an= d 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 th= is hash table is dynamic, as well; both can change anytime. For example, wh= en a flow starts, we look up the hash table with the corresponding IP and r= etrieve the username. We need to hold this username until the flow terminat= es, although we removed this IP key from the hash table (multithread). That= 's why we have RCU and defer queue is necessary for high performance. I= n my application, I need to know the number of IP-username entries. These n= umbers 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 avai= lable 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 rec= laim. Does it makes sense to have an API that just does the reclaim (and re= turns 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 reclaim. = 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 recla= im. I am trying to figure out which is better, calling reclaim or retrievin= g the 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 accur= ate number. Calling the reclaim API on an empty defer queue does not consum= e 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. W= hy 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.<= br> > Ack. This will be just a wrapper around the rte_rcu_qsbr_dq_reclaim. >
> >
> >
> > > >
> > > > I think if you need a non-blocking and multithreaded ha= sh table, an RCU-enabled hash table is necessary. Also, this API is necessa= ry if you need to get the actual matchable size.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Feb 19, 2024 at 8:36=E2=80=AFPM Medvedkin, Vlad= imir <= vladimir.medvedkin@intel.com> wrote:
> > > > Hi Abdullah,
> > > >
> > > > Could you please tell more about use cases where this A= PI may be useful?
> > > >
> > > > >a new API to get the hidden key count in the hash t= able if the rcu qsbr is enabled
> > > >
> > > > Here in commit message and down below in doxygen commen= ts, I think this
> > > > statement should be more specific because rcu can be cr= eated with
> > > > RTE_HASH_QSBR_MODE_SYNC mode i.e. without defer queue.<= br> > > > >
> > > > Also, new API must be reflected in release notes
> > > >
> > > > On 07/02/2024 15:33, Abdullah =C3=96mer Yama=C3=A7 wrot= e:
> > > > > This patch introduce a new API to get the hidden k= ey count in the hash
> > > > > table if the rcu qsbr is enabled. When using rte_h= ash_count with rcu
> > > > > qsbr enabled, it will return the number of element= s that are not in the
> > > > > free queue. Unless rte_rcu_qsbr_dq_reclaim is call= ed, the number of
> > > > > elements in the defer queue will not be counted an= d 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 <<= a href=3D"mailto:aomeryamac@gmail.com" target=3D"_blank">aomeryamac@gmail.c= om>
> > > > >
> > > > > ---
> > > > > 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> > > > > > Cc: Vladimir Medvedkin <vladimir.medvedkin@intel.com= >
> > > > > ---
> > > > >=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(const str= uct 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)
> > > > > +{
> > > > > +=C2=A0 =C2=A0 =C2=A0if (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()
> > > > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r= eturn -EINVAL;
> > > > why not just return 0?
> > > > > +
> > > > > +=C2=A0 =C2=A0 =C2=A0return rte_rcu_qsbr_dq_count(= h->dq);
> > > > > +}
> > > > > +
> > > > >=C2=A0 =C2=A0int32_t
> > > > >=C2=A0 =C2=A0rte_hash_count(const struct rte_hash *= h)
> > > > >=C2=A0 =C2=A0{
> > > > > diff --git a/lib/hash/rte_hash.h b/lib/hash/rte_ha= sh.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 queu= e 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 invali= d
> > > > > + *=C2=A0 =C2=A0- A value indicating how many reco= rds were inserted in the table.
> > > > did you mean how many records are kept in defer queue?<= br> > > > > > + */
> > > > > +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 the ha= sh table
> > > > >=C2=A0 =C2=A0 * @param h
> > > > > diff --git a/lib/hash/version.map b/lib/hash/versi= on.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_with_ha= sh;
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0rte_hash_add_key_with_ha= sh_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. The sam= e 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_alg; > > > > >=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(struc= t 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 queue.=
> > > > > + */
> > > > > +unsigned int rte_rcu_qsbr_dq_count(struct rte_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 rte_rcu= _qsbr_dq *dq, unsigned int n,
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0unsigned int *freed, uns= igned int *pending, unsigned int *available);
> > > > >=C2=A0 =C2=A0
> > > > > +/**
> > > > > + * Return the number of entries in a defer queue.=
> > > > > + *
> > > > > + * @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/version= .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_create;<= br> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0rte_rcu_qsbr_dq_delete;<= br> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0rte_rcu_qsbr_dq_enqueue;=
> > > > > +=C2=A0 =C2=A0 =C2=A0rte_rcu_qsbr_dq_count;
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0rte_rcu_qsbr_dq_reclaim;=
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0rte_rcu_qsbr_dump;
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0rte_rcu_qsbr_get_memsize= ;
> > > >
> > > > --
> > > > Regards,
> > > > Vladimir
> > > >
> > >
> >
>

--000000000000cfdb4c06126fab40--