>-----Original Message-----
>From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@arm.com]
>> >-----Original Message-----
>> >From: Stephen Hemminger [mailto:step...@networkplumber.org]
>> >On Fri, 28 Sep 2018 10:23:44 -0700
>> >Yipeng Wang <yipeng1.w...@intel.com> wrote:
>> >
>> >> + /* clear free extendable bucket ring and memory */
>> >> + if (h->ext_table_support) {
>> >> + memset(h->buckets_ext, 0, h->num_buckets *
>> >> + sizeof(struct
>> rte_hash_bucket));
>> >> + while (rte_ring_dequeue(h->free_ext_bkts, &ptr) == 0)
>> >> + rte_pause();
>> >
>> >Pause is much to short. Maybe nanosleep or sched_yield()?
>>
>> Hmm.. As a second thought, maybe we don't need any pause/sleep here?
>>
>> It is not a waiting loop and in multithreading case it is in the writer lock
>> so
>> this thread Should be the only thread operating this data structure.
>>
>> What do you think?
>Yes, this is a single thread use case. This is resetting the ring.
>
[Wang, Yipeng] If people agree on this, I can have a separate patch later to
remove the pause.
>>
>> BTW Honnappa, in the lock free implementation, is hash_reset protected?
>> We should indicate in the API doc which API is supposed to be protected by
>> user.
>I do not understand the use case for hash_reset API. Why not call hash_free
>and hash_create?
>But, lock free implementation does not handle hash_reset. I will document it
>in the next version.
>
[Wang, Yipeng]
I assume reset maybe still faster than free and create. Also, after free, you
cannot guarantee that
the creation can succeed. It might also require less user-level code by using
reset.
I agree that in most use cases people can just free and create a new one.
