[dpdk-dev] [PATCH v3] hash table: add an iterator over conflicting entries
Michel Machado
michel at digirati.com.br
Wed Sep 5 19:52:09 CEST 2018
Hi Yipeng,
On 09/04/2018 04:57 PM, Wang, Yipeng1 wrote:
>> -----Original Message-----
>> From: Michel Machado [mailto:michel at 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 algorithm and not touching
>> the header files that applications use. But, yes, your solution would
>> enable applications to allocate iterator states as local variables as well.
>>
>
> [Wang, Yipeng] I didn't mean to expose the private fields. But only the
> Type. For example, rte_hash does not expose its private fields to users.
> One can change the fields without changing API.
The fact that struct rte_hash does not expose its private fields but
only its type to applications means that a compiler cannot find out the
byte length of struct rte_hash using only the header rte_hash.h. Thus,
an application cannot allocate memory on its own (e.g. as a local
variable) for a struct rte_hash. An application can, however, have a
pointer to a struct rte_hash since the byte length of a pointer only
depends on the architecture of the machine. This is the motivation
behind having struct rte_hash_iterator_state in rte_hash.h only holding
an array of bytes.
There are good reasons to implement struct rte_hash as it is. For
examples, struct rte_hash can change its byte length between versions of
DPDK even if applications are dynamically linked to DPDK and not
recompiled. Moreover a hash table is unlikely to be so short-lived as an
iterator.
[ ]'s
Michel Machado
More information about the dev
mailing list