[dpdk-dev] [PATCH] hash: move rte_hash structure to C file and make it internal
Matthew Hall
mhall at mhcomputing.net
Thu Jul 9 22:42:17 CEST 2015
On Thu, Jul 09, 2015 at 09:12:23AM +0100, Bruce Richardson wrote:
> Thanks for the feedback Matthew. Can you suggest a function prototype for such
> a walk operation that would make it useful for you. While we can keep the
> hash structure public, I'd prefer if we could avoid it, as it makes making changes
> hard due to ABI issues.
>
> /Bruce
Hi Bruce,
I understand about the ABI issues. Hence my suggestion of an iterator if the
structs are opaque. The names could be something like these:
rte_hash_iterate(_safe)
rte_hash_foreach(_safe)
If required due to the implementation, the safe version would be similar to
what's seen in BSD queue.h, where you can do a slower iteration that allows
removing a current entry without corrupting the table or iterator.
Then the function would look something like this:
rte_hash_iterate(rte_hash_t* h, rte_hash_callback_t callback, void* data)
rte_hash_iterate(rte_hash_t* h, rte_hash_callback_t callback, void* data)
rte_hash_iterate(rte_hash_t* h, rte_hash_callback_t callback, void* data)
rte_hash_callback_t would be a typedef of a function pointer for a callback
function, something like this on the function depending how it works inside
the hash:
int application_hash_callback(void* key, void* value, void* data)
int application_hash_callback(void* key, rte_hash_entry_t* entry, void* data)
int application_hash_callback(void* key, void* key, void* value, void* data)
The data pointer will contain the same pointer passed to the iterator. If the
iteration function returns non-zero, iteration could be discontinued, as the
client code found what it wanted already.
Threading synchronization responsibility will fall on the client as before.
The iterator should say if it's thread-safe for read-only, read-write, or
unsafe for anything, etc.
Matthew.
More information about the dev
mailing list