From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mta113.f1.k8.com.br (mta113.f1.k8.com.br [187.73.32.185]) by dpdk.org (Postfix) with ESMTP id A8B7F235 for ; Sun, 19 Aug 2018 00:45:18 +0200 (CEST) X-HN-S: bWljaGVsQGRpZ2lyYXRpLmNvbS5icg== X-DKIM: OpenDKIM Filter v2.6.8 smtpz.f1.k8.com.br 4688080040 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digirati.com.br; s=default; t=1534632316; bh=WCjxWus0/WGGdDdpk6euC8eZWcKGnRrSu72rPEe51Gs=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Okhr0pafWg3XXdlYCWtuVBLJBLTNLkH4k4jjiiZKk1fHrpTLMNUE/8xpMWt1gmcQ/ kt/QKw+W/A06I/mvUDP6fJHw3jvJGqmcH2F8H0XB/BuPjfPfEu1ufYEDsoA38ReZbC NjXf/k8rzrBmtpmeKpH2maqbZ7GdZACZlJOQYttw= X-HN-R: bmRAYXJtLmNvbQ== X-HN-S: bWljaGVsQGRpZ2lyYXRpLmNvbS5icg== X-HN-R: c3RlcGhlbkBuZXR3b3JrcGx1bWJlci5vcmc= X-HN-S: bWljaGVsQGRpZ2lyYXRpLmNvbS5icg== X-HN-R: Y2hhcmxpZS50YWlAaW50ZWwuY29t X-HN-S: bWljaGVsQGRpZ2lyYXRpLmNvbS5icg== X-HN-R: c2FtZWguZ29icmllbEBpbnRlbC5jb20= X-HN-S: bWljaGVsQGRpZ2lyYXRpLmNvbS5icg== X-HN-R: a2VpdGgud2lsZXNAaW50ZWwuY29t X-HN-S: bWljaGVsQGRpZ2lyYXRpLmNvbS5icg== X-HN-R: eWlwZW5nMS53YW5nQGludGVsLmNvbQ== X-HN-S: bWljaGVsQGRpZ2lyYXRpLmNvbS5icg== X-HN-R: ZG91Y2V0dGVAYnUuZWR1 X-HN-S: bWljaGVsQGRpZ2lyYXRpLmNvbS5icg== X-HN-R: ZGV2QGRwZGsub3Jn X-HN-S: bWljaGVsQGRpZ2lyYXRpLmNvbS5icg== X-HN-R: cGFibG8uZGUubGFyYS5ndWFyY2hAaW50ZWwuY29t X-HN-S: bWljaGVsQGRpZ2lyYXRpLmNvbS5icg== X-HN-R: YnJ1Y2UucmljaGFyZHNvbkBpbnRlbC5jb20= X-HN-S: bWljaGVsQGRpZ2lyYXRpLmNvbS5icg== X-HN-R: cWlhb2JpbmZAYnUuZWR1 X-HN-S: bWljaGVsQGRpZ2lyYXRpLmNvbS5icg== X-HN-R: aG9ubmFwcGEubmFnYXJhaGFsbGlAYXJtLmNvbQ== Received: from [192.168.1.4] (pool-173-48-214-200.bstnma.fios.verizon.net [173.48.214.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtpz.f1.k8.com.br (Postfix) with ESMTPSA id 4688080040; Sat, 18 Aug 2018 22:45:10 +0000 (UTC) To: Honnappa Nagarahalli , "Fu, Qiaobin" , "Richardson, Bruce" , "De Lara Guarch, Pablo" Cc: "dev@dpdk.org" , "Doucette, Cody, Joseph" , "Wang, Yipeng1" , "Wiles, Keith" , "Gobriel, Sameh" , "Tai, Charlie" , Stephen Hemminger , nd References: <5e809298-ee0e-f03f-e83a-59b764e3a9b8@digirati.com.br> From: Michel Machado Organization: Digirati Internet LTDA. Message-ID: Date: Sat, 18 Aug 2018 18:45:08 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 21 Aug 2018 22:23:55 +0200 Subject: Re: [dpdk-dev] [PATCH v2] hash table: add an iterator over conflicting entries X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2018 22:45:19 -0000 On 08/17/2018 03:41 PM, Honnappa Nagarahalli wrote: >> Do we also need to have 'rte_hash_iterate_conflict_entries_with_hash' API? > > I may have not understood the question. We are already working with the hash (i.e. sig). Did you mean something else? > > Let me elaborate. For the API 'rte_hash_lookup', there are multiple variations such as 'rte_hash_lookup_with_hash', 'rte_hash_lookup_data', 'rte_hash_lookup_with_hash_data' etc. We do not need to create similar variations for 'rte_hash_iterate_conflict_entries' API right now. But the naming of the API should be such that these variations can be created in the future. So you mean that we should actually name rte_hash_iterator_conflict_entries_init() as rte_hash_iterator_conflict_entries_init_with_hash()? I'd be fine with this. >> diff --git a/lib/librte_hash/rte_hash.h b/lib/librte_hash/rte_hash.h >> index f71ca9fbf..7ecb6a7eb 100644 >> --- a/lib/librte_hash/rte_hash.h >> +++ b/lib/librte_hash/rte_hash.h >> @@ -61,6 +61,11 @@ struct rte_hash_parameters { >> /** @internal A hash table structure. */ struct rte_hash; >> >> +/** @internal A hash table conflict iterator state structure. */ >> +struct rte_conflict_iterator_state { >> + uint8_t space[64]; >> +}; >> + > Needs aligning to cache line. Ok. >> The size depends on the current size of the state, which is subject to change with the algorithm used. > > We chose a size that should be robust for any future underlying algorithm. Do you have a suggestion on how to go about it? We chose to have a simple struct to enable applications to allocate a state as a local variable and avoid a memory allocation. > > This looks fine after your explanation. The structure name can be changed to 'rte_iterator_state' so that it can be used in other iterator APIs too. I like this suggestion. What about the name "rte_hash_iterator_state" to make it specific to the hash table? [ ]'s Michel Machado