clarification on RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF flag

clarification on RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF flag

[venkatesh bs]

[-- Attachment #1: Type: text/plain, Size: 595 bytes --]

Hi All,

In multithreaded/Multicore  environment can we use
RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF
independently,
or this flag should always be used with
RTE_HASH_EXTRA_FLAGS_MULTI_WRITER_ADD.

We are trying to create and access the hash table with
RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF
only.
We are getting crashes in multi core environments , we debugged nothing
wrong in the application , everything looks good.

We call rte_hash_del_key() first and from the returned position we are
calling rte_hash_free_key_with_position().

Please let me know if we missed something.

Thanks,
Venkatesh.

[-- Attachment #2: Type: text/html, Size: 2006 bytes --]

Re: clarification on RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF flag

[venkatesh bs]

[-- Attachment #1: Type: text/plain, Size: 1300 bytes --]

Hi All,

In multithreaded/Multicore  environment can we use
RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF
independently,
or this flag should always be used with
RTE_HASH_EXTRA_FLAGS_MULTI_WRITER_ADD.

We are trying to create and access the hash table with
RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF
only.
We are getting crashes in multi core environments , we debugged nothing
wrong in the application , everything looks good.

We call rte_hash_del_key() first and from the returned position we are
calling rte_hash_free_key_with_position().

Please let me know if we missed something.

Thanks,
Venkatesh.

On Wed, Jul 6, 2022 at 9:15 AM venkatesh bs <venki.bsv@gmail.com> wrote:

> Hi All,
>
> In multithreaded/Multicore  environment can we use RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF
> independently,
> or this flag should always be used with
> RTE_HASH_EXTRA_FLAGS_MULTI_WRITER_ADD.
>
> We are trying to create and access the hash table with RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF
> only.
> We are getting crashes in multi core environments , we debugged nothing
> wrong in the application , everything looks good.
>
> We call rte_hash_del_key() first and from the returned position we are
> calling rte_hash_free_key_with_position().
>
> Please let me know if we missed something.
>
> Thanks,
> Venkatesh.
>

[-- Attachment #2: Type: text/html, Size: 4344 bytes --]

Re: clarification on RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF flag

[venkatesh bs]

[-- Attachment #1: Type: text/plain, Size: 2029 bytes --]

Hi All,

In multithreaded/Multicore  environment can we use
RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF
independently,
or this flag should always be used with
RTE_HASH_EXTRA_FLAGS_MULTI_WRITER_ADD.

We are trying to create and access the hash table with
RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF
only.
We are getting crashes in multi core environments , we debugged nothing
wrong in the application , everything looks good.

We call rte_hash_del_key() first and from the returned position we are
calling rte_hash_free_key_with_position().

Please let me know if we missed something.

Thanks,
Venkatesh.

On Wed, Jul 6, 2022 at 7:07 PM venkatesh bs <venki.bsv@gmail.com> wrote:

> Hi All,
>
> In multithreaded/Multicore  environment can we use RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF
> independently,
> or this flag should always be used with
> RTE_HASH_EXTRA_FLAGS_MULTI_WRITER_ADD.
>
> We are trying to create and access the hash table with RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF
> only.
> We are getting crashes in multi core environments , we debugged nothing
> wrong in the application , everything looks good.
>
> We call rte_hash_del_key() first and from the returned position we are
> calling rte_hash_free_key_with_position().
>
> Please let me know if we missed something.
>
> Thanks,
> Venkatesh.
>
> On Wed, Jul 6, 2022 at 9:15 AM venkatesh bs <venki.bsv@gmail.com> wrote:
>
>> Hi All,
>>
>> In multithreaded/Multicore  environment can we use RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF
>> independently,
>> or this flag should always be used with
>> RTE_HASH_EXTRA_FLAGS_MULTI_WRITER_ADD.
>>
>> We are trying to create and access the hash table with RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF
>> only.
>> We are getting crashes in multi core environments , we debugged nothing
>> wrong in the application , everything looks good.
>>
>> We call rte_hash_del_key() first and from the returned position we are
>> calling rte_hash_free_key_with_position().
>>
>> Please let me know if we missed something.
>>
>> Thanks,
>> Venkatesh.
>>
>

[-- Attachment #2: Type: text/html, Size: 6698 bytes --]

Re: clarification on RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF flag

[Stephen Hemminger]

On Wed, 6 Jul 2022 19:07:54 +0530
venkatesh bs <venki.bsv@gmail.com> wrote:

> Hi All,
> 
> In multithreaded/Multicore  environment can we use
> RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF
> independently,
> or this flag should always be used with
> RTE_HASH_EXTRA_FLAGS_MULTI_WRITER_ADD.
> 
> We are trying to create and access the hash table with
> RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF
> only.
> We are getting crashes in multi core environments , we debugged nothing
> wrong in the application , everything looks good.
> 
> We call rte_hash_del_key() first and from the returned position we are
> calling rte_hash_free_key_with_position().
> 
> Please let me know if we missed something.
> 
> Thanks,
> Venkatesh.

Repeating same question doesn't get answer faster.

Read the code, it is fairly straightforward.

The multi-writer add means that writers take a lock.
If doing lock free support then:
  1. It is up to your application to use a single writer and/or
     wrap writer calls in a lock.

  2. You need to use RCU mechanism to guarantee that no reader
     will access a deleted entry. Something like:

     rte_hash_del_key()
     synchronize_rcu()
     rte_hash_free_key_with_position()

     You can use either the DPDK RCU library or the userspace RCU library.
     Read that documentation, RCU is non-trivial change.

RE: clarification on RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF flag

[Honnappa Nagarahalli]

<snip>

> On Wed, 6 Jul 2022 19:07:54 +0530
> venkatesh bs <venki.bsv@gmail.com> wrote:
> 
> > Hi All,
> >
> > In multithreaded/Multicore  environment can we use
> > RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF
> > independently,
This flag is about reader-writer concurrency (not writer-writer concurrency). Reader-writer concurrency will use lock-free algorithm allowing for the data plane to scale well.

> > or this flag should always be used with
> > RTE_HASH_EXTRA_FLAGS_MULTI_WRITER_ADD.
If you have multiple writers, you need to enable this flag. This is unrelated to RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF.

> >
> > We are trying to create and access the hash table with
> > RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF
> > only.
> > We are getting crashes in multi core environments , we debugged
> > nothing wrong in the application , everything looks good.
If the crash is happening while adding/deleting keys and there are multiple writers, enabling RTE_HASH_EXTRA_FLAGS_MULTI_WRITER_ADD might solve the problem.

> >
> > We call rte_hash_del_key() first and from the returned position we are
> > calling rte_hash_free_key_with_position().
> >
> > Please let me know if we missed something.
> >
> > Thanks,
> > Venkatesh.
> 
> Repeating same question doesn't get answer faster.
> 
> Read the code, it is fairly straightforward.
> 
> The multi-writer add means that writers take a lock.
> If doing lock free support then:
>   1. It is up to your application to use a single writer and/or
>      wrap writer calls in a lock.
> 
>   2. You need to use RCU mechanism to guarantee that no reader
>      will access a deleted entry. Something like:
> 
>      rte_hash_del_key()
>      synchronize_rcu()
>      rte_hash_free_key_with_position()
> 
>      You can use either the DPDK RCU library or the userspace RCU library.
>      Read that documentation, RCU is non-trivial change.
RCU is integrated in the hash library. You could use that as well. Look at ' rte_hash_rcu_qsbr_add' API for more details.

>