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 806881559 for ; Wed, 5 Sep 2018 19:52:21 +0200 (CEST) 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 48A1780051; Wed, 5 Sep 2018 17:52:12 +0000 (UTC) X-DKIM: OpenDKIM Filter v2.6.8 smtpz.f1.k8.com.br 48A1780051 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digirati.com.br; s=default; t=1536169938; bh=utdgQIdppGW+3mpaVWuF6nFuVnc0M4lBDQHtAv1/VEg=; h=Subject:To:From:Date:Feedback-ID; b=obRGK+yB/zv0zxrpyQtxuKuNUJKpgN+GZEiDzrqJA2Bgq55IP3EvGbeVNYBFUNUbm qVDZlq8JkD0oXN52oY9p/UepylDxO9gjmy11TtqMSTG2Rxn2xG6wI0LyhKaB2DGUAD U3EGCpnHhIG2X+6Zh9AG3veYi2Mi7gJo7bd2DiXc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=k8.com.br; s=default; t=1536169938; bh=utdgQIdppGW+3mpaVWuF6nFuVnc0M4lBDQHtAv1/VEg=; h=Subject:To:From:Date:Feedback-ID; b=iFZFjHCLoNg4FDP5bSST0aQz0vVy3cHNQYjPqRCv4EmFnEn5rE2lJYmTwaLKksG8V f/hofMRXf5M0wIg+1WlbDj4ei5fWnClZqAQ8W4Ud2DeB56DIvpKNWXfUv+VheFAIyo QQOQbSO2/6sVBJ5bDJRhttvc7qahe40+x8AGJz1w= To: "Wang, Yipeng1" , Qiaobin Fu , "Richardson, Bruce" , "De Lara Guarch, Pablo" Cc: "dev@dpdk.org" , "doucette@bu.edu" , "Wiles, Keith" , "Gobriel, Sameh" , "Tai, Charlie" , "stephen@networkplumber.org" , "nd@arm.com" , "honnappa.nagarahalli@arm.com" References: <20180831165101.20026-1-qiaobinf@bu.edu> From: Michel Machado Organization: Digirati Internet LTDA. Message-ID: <037eca0c-a1e5-a7fa-8b5e-d7a35006e852@digirati.com.br> Date: Wed, 5 Sep 2018 13:52:09 -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-HN-S: bWljaGVsQGRpZ2lyYXRpLmNvbS5icg== X-HN-R: aG9ubmFwcGEubmFnYXJhaGFsbGlAYXJtLmNvbSxuZEBhcm0uY29tLHN0ZXBoZW5AbmV0d29ya3BsdW1iZXIub3JnLGNoYXJsaWUudGFpQGludGVsLmNvbSxzYW1laC5nb2JyaWVsQGludGVsLmNvbSxrZWl0aC53aWxlc0BpbnRlbC5jb20sZG91Y2V0dGVAYnUuZWR1LGRldkBkcGRrLm9yZyxwYWJsby5kZS5sYXJhLmd1YXJjaEBpbnRlbC5jb20sYnJ1Y2UucmljaGFyZHNvbkBpbnRlbC5jb20scWlhb2JpbmZAYnUuZWR1LHlpcGVuZzEud2FuZ0BpbnRlbC5jb20= Feedback-ID: MjAxODA5MDU=:bWljaGVsQGRpZ2lyYXRpLmNvbS5icg==:ZGlnaXJhdGkuY29tLmJy:k8networks X-Mailman-Approved-At: Thu, 06 Sep 2018 15:08:09 +0200 Subject: Re: [dpdk-dev] [PATCH v3] 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: Wed, 05 Sep 2018 17:52:22 -0000 Hi Yipeng, On 09/04/2018 04:57 PM, Wang, Yipeng1 wrote: >> -----Original Message----- >> From: Michel Machado [mailto:michel@digirati.com.br] > >> Exposing the private fields would bind the interface with the >> current implementation of the hash table. In the way we are proposing, >> one should be able to replace the underlying algorithm and not touching >> the header files that applications use. But, yes, your solution would >> enable applications to allocate iterator states as local variables as well. >> > > [Wang, Yipeng] I didn't mean to expose the private fields. But only the > Type. For example, rte_hash does not expose its private fields to users. > One can change the fields without changing API. The fact that struct rte_hash does not expose its private fields but only its type to applications means that a compiler cannot find out the byte length of struct rte_hash using only the header rte_hash.h. Thus, an application cannot allocate memory on its own (e.g. as a local variable) for a struct rte_hash. An application can, however, have a pointer to a struct rte_hash since the byte length of a pointer only depends on the architecture of the machine. This is the motivation behind having struct rte_hash_iterator_state in rte_hash.h only holding an array of bytes. There are good reasons to implement struct rte_hash as it is. For examples, struct rte_hash can change its byte length between versions of DPDK even if applications are dynamically linked to DPDK and not recompiled. Moreover a hash table is unlikely to be so short-lived as an iterator. [ ]'s Michel Machado