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.