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 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
