On 09/12/2018 04:37 PM, Honnappa Nagarahalli wrote:
+int32_t
+rte_hash_iterator_init(const struct rte_hash *h,
+ struct rte_hash_iterator_state *state) {
+ struct rte_hash_iterator_istate *__state;
'__state' can be replaced by 's'.
+
+ RETURN_IF_TRUE(((h == NULL) || (state == N
Hi Michel,
I applied your patch and tweaked the code to run few performance tests
on Arm (Cortex-A72, 1.3GHz) and x86 (Intel Xeon CPU E5-2660 v4 @ 2.00GHz). The
perf code looks as follows:
count_b = rte_rdtsc_precise();
int k = 0;
rte_hash_iterator_init(tbl_rw_tes
On 09/05/2018 06:13 PM, Honnappa Nagarahalli wrote:
+ uint32_t next;
+ uint32_t total_entries;
+};
This structure can be moved to rte_cuckoo_hash.h file.
What's the purpose of moving this struct to a header file since it's only
used in the C file rte_
On 09/05/2018 04:27 PM, Wang, Yipeng1 wrote:
Hmm I see, it falls back to my original thought to have malloc inside the init
function..
Thanks for the explanation. :)
So I guess with your implementation, in future if we change the internal state
to be larger,
the ABI will be broken.
If tha
Hi Honnappa,
On 09/02/2018 06:05 PM, Honnappa Nagarahalli wrote:
+/* istate stands for internal state. */ struct rte_hash_iterator_istate
+{
+ const struct rte_hash *h;
This can be outside of this structure. This will help keep the API definitions
consistent with existing APIs. Please see
Hi Yipeng,
On 09/04/2018 04:57 PM, Wang, Yipeng1 wrote:
-Original Message-
From: Michel Machado [mailto:mic...@digirati.com.br]
Exposing the private fields would bind the interface with the
current implementation of the hash table. In the way we are proposing,
one should be able t
Hi Yipeng,
On 09/04/2018 03:51 PM, Wang, Yipeng1 wrote:
Hmm, I guess my comment is for code readability. If we don’t need the extra
state that would be great.
Notice that applications only see the public, opaque state. And the
private versions are scoped to the C file where they are neede
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_mem
Hi Gaëtan,
On 08/31/2018 06:53 PM, Gaëtan Rivet wrote:
Hi Qiaobin,
This work seems interesting, but is difficult to follow because
the previous discussion is not referenced.
You can find a how-to there:
http://doc.dpdk.org/guides/contributing/patches.html#sending-patches
--in-reply-to is use
-Original Message-
From: Michel Machado
Sent: Tuesday, September 4, 2018 2:37 PM
To: Honnappa Nagarahalli ; Qiaobin Fu
; bruce.richard...@intel.com; pablo.de.lara.gua...@intel.com
Cc: dev@dpdk.org; douce...@bu.edu; keith.wi...@intel.com;
sameh.gobr...@intel.com; charlie@intel.com;
Hmm I see, it falls back to my original thought to have malloc inside the init
function..
Thanks for the explanation. :)
So I guess with your implementation, in future if we change the internal state
to be larger,
the ABI will be broken. BTW, this patch set also changes API so proper notice
is
Thanks for your reply.
>-Original Message-
>From: Michel Machado [mailto:mic...@digirati.com.br]
>Exposing the private fields would bind the interface with the
>current implementation of the hash table. In the way we are proposing,
>one should be able to replace the underlying algorit
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
Thanks for the patch.
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 fun
Hi Qiaobin,
Thank you for the patch. Please see few comments inline.
-Original Message-
From: Qiaobin Fu
Sent: Friday, August 31, 2018 11:51 AM
To: bruce.richard...@intel.com; pablo.de.lara.gua...@intel.com
Cc: dev@dpdk.org; douce...@bu.edu; keith.wi...@intel.com;
sameh.gobr...@
Hi Qiaobin,
This work seems interesting, but is difficult to follow because
the previous discussion is not referenced.
You can find a how-to there:
http://doc.dpdk.org/guides/contributing/patches.html#sending-patches
--in-reply-to is useful to check which comments were already made and
understa
Function rte_hash_iterate_conflict_entries() iterates over
the entries that conflict with an incoming entry.
Iterating over conflicting entries enables one to decide
if the incoming entry is more valuable than the entries already
in the hash table. This is particularly useful after
an insertion fa
Function rte_hash_iterate_conflict_entries() iterates over
the entries that conflict with an incoming entry.
Iterating over conflicting entries enables one to decide
if the incoming entry is more valuable than the entries already
in the hash table. This is particularly useful after
an insertion fa
18 matches
Mail list logo
