From: "Wang, Yipeng1" <yipeng1.wang@intel.com>
To: Michel Machado <michel@digirati.com.br>,
Qiaobin Fu <qiaobinf@bu.edu>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
"De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"doucette@bu.edu" <doucette@bu.edu>,
"Wiles, Keith" <keith.wiles@intel.com>,
"Gobriel, Sameh" <sameh.gobriel@intel.com>,
"Tai, Charlie" <charlie.tai@intel.com>,
"stephen@networkplumber.org" <stephen@networkplumber.org>,
"nd@arm.com" <nd@arm.com>,
"honnappa.nagarahalli@arm.com" <honnappa.nagarahalli@arm.com>
Subject: Re: [dpdk-dev] [PATCH v3] hash table: add an iterator over conflicting entries
Date: Tue, 4 Sep 2018 19:51:59 +0000 [thread overview]
Message-ID: <D2C4A16CA39F7F4E8E384D204491D7A6614A1A83@ORSMSX105.amr.corp.intel.com> (raw)
In-Reply-To: <d9564261-3c0d-7237-d36b-5e13d14464db@digirati.com.br>
Hmm, I guess my comment is for code readability. If we don’t need the extra state that would be great.
I think "rte_hash" is defined as an internal data structure but expose the type to the public header. Would this work?
I propose to malloc inside function mostly because I think it is cleaner to the user. But your argument is
valid. Depending on use case I think it is OK.
Another comment is you put the total_entry in the state, is it for performance of the rte_hash_iterate?
If you use it to iterate conflict entries, especially If you reuse same "state" struct and init it again and again for different keys,
would this slow down the performance for your specific use case?
Also iterate_conflic_entry may need reader lock protection.
Thanks
Yipeng
>-----Original Message-----
>From: Michel Machado [mailto:michel@digirati.com.br]
>Sent: Tuesday, September 4, 2018 12:08 PM
>To: Wang, Yipeng1 <yipeng1.wang@intel.com>; Qiaobin Fu <qiaobinf@bu.edu>; Richardson, Bruce <bruce.richardson@intel.com>; De
>Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
>Cc: dev@dpdk.org; doucette@bu.edu; Wiles, Keith <keith.wiles@intel.com>; Gobriel, Sameh <sameh.gobriel@intel.com>; Tai, Charlie
><charlie.tai@intel.com>; stephen@networkplumber.org; nd@arm.com; honnappa.nagarahalli@arm.com
>Subject: Re: [PATCH v3] hash table: add an iterator over conflicting entries
>
>Hi Yipeng,
>
>On 09/04/2018 02:55 PM, Wang, Yipeng1 wrote:
>> Do we need both of the state and istate struct? struct rte_hash_iterator_state seems not doing much.
>> How about we only have one "state" struct and just not expose the internals to the public API, similar to the
>> rte_hash struct or rte_member_setsum struct.
>> And in _init function use rte_malloc to allocate the state and add a _free function to free it.
>
> The purpose of have struct state is to enable applications to
>allocate iterator states on their execution stack or embedding iterator
>states in larger structs to avoid an extra malloc()/free().
>
> Do you foresee that the upcoming new underlying algorithm of hash
>tables will need to dynamically allocate iterator states?
>
>[ ]'s
>Michel Machado
next prev parent reply other threads:[~2018-09-04 19:52 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-31 16:51 Qiaobin Fu
2018-08-31 22:53 ` Gaëtan Rivet
2018-09-04 18:46 ` Michel Machado
2018-09-02 22:05 ` Honnappa Nagarahalli
2018-09-04 19:36 ` Michel Machado
2018-09-05 22:13 ` Honnappa Nagarahalli
2018-09-06 14:28 ` Michel Machado
2018-09-12 20:37 ` Honnappa Nagarahalli
2018-09-20 19:50 ` Michel Machado
2018-09-04 18:55 ` Wang, Yipeng1
2018-09-04 19:07 ` Michel Machado
2018-09-04 19:51 ` Wang, Yipeng1 [this message]
2018-09-04 20:26 ` Michel Machado
2018-09-04 20:57 ` Wang, Yipeng1
2018-09-05 17:52 ` Michel Machado
2018-09-05 20:27 ` Wang, Yipeng1
2018-09-06 13:34 ` Michel Machado
2018-10-09 19:29 ` [dpdk-dev] [PATCH v4 1/2] hash table: fix a bug in rte_hash_iterate() Qiaobin Fu
2018-10-09 19:29 ` [dpdk-dev] [PATCH v4 2/2] hash table: add an iterator over conflicting entries Qiaobin Fu
2018-10-10 2:54 ` Wang, Yipeng1
2018-10-10 1:55 ` [dpdk-dev] [PATCH v4 1/2] hash table: fix a bug in rte_hash_iterate() Wang, Yipeng1
-- strict thread matches above, loose matches on Subject: below --
2018-08-30 15:56 [dpdk-dev] [PATCH v3] hash table: add an iterator over conflicting entries Qiaobin Fu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D2C4A16CA39F7F4E8E384D204491D7A6614A1A83@ORSMSX105.amr.corp.intel.com \
--to=yipeng1.wang@intel.com \
--cc=bruce.richardson@intel.com \
--cc=charlie.tai@intel.com \
--cc=dev@dpdk.org \
--cc=doucette@bu.edu \
--cc=honnappa.nagarahalli@arm.com \
--cc=keith.wiles@intel.com \
--cc=michel@digirati.com.br \
--cc=nd@arm.com \
--cc=pablo.de.lara.guarch@intel.com \
--cc=qiaobinf@bu.edu \
--cc=sameh.gobriel@intel.com \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).