From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mta123.f1.k8.com.br (mta123.f1.k8.com.br [187.73.32.199]) by dpdk.org (Postfix) with ESMTP id 14C44DED for ; Tue, 21 Aug 2018 14:42:02 +0200 (CEST) X-HN-S: bWljaGVsQGRpZ2lyYXRpLmNvbS5icg== X-DKIM: OpenDKIM Filter v2.6.8 smtpz.f1.k8.com.br 81025601B0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digirati.com.br; s=default; t=1534855320; bh=ihItgdkbP2yPVmQYwW5olAPvm0RBJZgff5U8vlDSyBk=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=TnrA0B8bEi38X8rgG4bgFHcIpla4xxoof1ialN3F6vws2PrLxMAxJmB03zP0EkhJB hXMzUwvH6nwTcxleaXuz9XjzWXVHNc8OHNdLiOB1rtXZqQWnULep6j3HVtXs2l5XTJ lR2Yb6aR9TKH1cQkew78PC9y69VqUqhpwB2KI80A= 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 81025601B0; Tue, 21 Aug 2018 12:41:54 +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> <12e971e0-41bd-2cd6-d80c-a7a486fd1046@digirati.com.br> From: Michel Machado Organization: Digirati Internet LTDA. Message-ID: Date: Tue, 21 Aug 2018 08:41:52 -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: Tue, 21 Aug 2018 12:42:03 -0000 On 08/21/2018 01:10 AM, Honnappa Nagarahalli wrote: > On 08/17/2018 03:41 PM, Honnappa Nagarahalli wrote: >> Can you elaborate more on using ' struct rte_conflict_iterator_state' as the argument for the API? >> >> If the API signature is changed to: rte_hash_iterate_conflict_entries (const struct rte_hash *h, void **key, void **data, const hash_sig_t sig, struct rte_conflict_iterator_state *state) - it will be inline with the existing APIs. Contents of 'state' must be initialized to 0 for the first call. This will also avoid creating 'rte_hash_iterator_conflict_entries_init' API. > > Testing `state' every time rte_hash_iterate_conflict_entries() is called to find out if it's the first call of the iterator will possibly add some small, but unnecessary, overhead on > rte_hash_iterate_conflict_entries() and constraints on struct rte_conflict_iterator_state. Moreover, > rte_hash_iterator_conflict_entries_init() enables one to easily add variations of the init function to initialize the state (e.g. using a key instead of a sig) and still use the exactly same iterator. > > IMO, I think, this over-head will be trivial. Looking at the function 'rte_hash_iterate_conflict_entries' the check for '(__state->vnext < RTE_HASH_BUCKET_ENTRIES * 2)' already exists. If the primary/secondary bucket indices are calculated as well in 'rte_hash_iterate_conflict_entries' API ('rte_hash_iterate' API does such calculations), storing them in the state can be avoided. I am wondering if it makes sense to benchmark with these changes and then take a decision? We have come up with the init function and struct rte_conflict_iterator_state in v2 to make the new iterator as future proof to a change of the underlying algorithm as possible. But going through your feedback, it seems to me that your top concern is to not deviate much of the current interface of rte_hash_iterate(). We are fine with pushing v3 using the interface you've suggested to avoid the init function and struct rte_conflict_iterator_state: int32_t rte_hash_iterate_conflict_entries__with_hash(const struct rte_hash *h, const void **key, void **data, hash_sig_t sig, uint32_t *next); [ ]'s Michel Machado