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 needed. People more familiar with API/ABI change policies may be able to help here. Just to confirm, is there anyway like I said for your application to have some long-live states and reuse them throughout the application so that you don’t have to have short-lived ones in stack? Thanks Yipeng > > 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
