From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <mhall@mhcomputing.net>
Received: from mail.mhcomputing.net (master.mhcomputing.net [74.208.46.186])
 by dpdk.org (Postfix) with ESMTP id 30B145A8B
 for <dev@dpdk.org>; Thu,  9 Jul 2015 22:45:11 +0200 (CEST)
Received: by mail.mhcomputing.net (Postfix, from userid 1000)
 id 4D5EC80C502; Thu,  9 Jul 2015 13:42:17 -0700 (PDT)
Date: Thu, 9 Jul 2015 13:42:17 -0700
From: Matthew Hall <mhall@mhcomputing.net>
To: Bruce Richardson <bruce.richardson@intel.com>
Message-ID: <20150709204217.GA11561@mhcomputing.net>
References: <1436354854-30700-1-git-send-email-pablo.de.lara.guarch@intel.com>
 <1436354854-30700-2-git-send-email-pablo.de.lara.guarch@intel.com>
 <20150708132142.GB5708@bricha3-MOBL3>
 <20150708165703.GA2551@mhcomputing.net>
 <20150709081222.GB8408@bricha3-MOBL3>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150709081222.GB8408@bricha3-MOBL3>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] hash: move rte_hash structure to C file and
 make it internal
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jul 2015 20:45:11 -0000

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.