From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mta112.f1.k8.com.br (mta112.f1.k8.com.br [187.73.32.184]) by dpdk.org (Postfix) with ESMTP id AF4AC4CAF for ; Mon, 27 Aug 2018 20:27:11 +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 20D3F80115; Mon, 27 Aug 2018 18:27:03 +0000 (UTC) X-DKIM: OpenDKIM Filter v2.6.8 smtpz.f1.k8.com.br 20D3F80115 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digirati.com.br; s=default; t=1535394429; bh=dwRWANKrf1XJkualxgTJvU2VFdPZepAJP04iPkh8S0c=; h=Subject:To:From:Date:Feedback-ID; b=wZ5VYVR61LUhxmYcNeg8coGOdjuu0lzUK+/gB5HAKSS3fwjkz7KqGl/TcBoBrOQAO 3Lk4DDYgf4cWHGfcw7HELWMo1kBHSnIjfALjnDllj0LeL0sBvUbBLbB36w62dpBaSk O0+/hUxIV+mS1gv2kj9OIR2cGlME5CqH6nBakoC4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=k8.com.br; s=default; t=1535394429; bh=dwRWANKrf1XJkualxgTJvU2VFdPZepAJP04iPkh8S0c=; h=Subject:To:From:Date:Feedback-ID; b=IkLsu3evMUJq9bS+drYX6ha0+EOAtgPyiTMTO4YFSyH6Pw6Q18gpToT9gyrOiue64 Z7eS+mz9xgtYZHc0wFjtiHJ0gQRVOmFPXvL3qjYv9YyqUTOsXFgxsh1WOACAIiDghZ uLlIJDJkYBk2bbAYMHf5nIsxV5d/cplf+jo28f+g= To: Honnappa Nagarahalli , "Wang, Yipeng1" , "Fu, Qiaobin" Cc: "dev@dpdk.org" , "Doucette, Cody, Joseph" , "Wiles, Keith" , "Gobriel, Sameh" , "Tai, Charlie" , Stephen Hemminger , nd , "Richardson, Bruce" , "De Lara Guarch, Pablo" 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: <4ffeda13-a200-2999-13a3-ee1257579f78@digirati.com.br> Date: Mon, 27 Aug 2018 14:27:01 -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: cGFibG8uZGUubGFyYS5ndWFyY2hAaW50ZWwuY29tLGJydWNlLnJpY2hhcmRzb25AaW50ZWwuY29tLG5kQGFybS5jb20sc3RlcGhlbkBuZXR3b3JrcGx1bWJlci5vcmcsY2hhcmxpZS50YWlAaW50ZWwuY29tLHNhbWVoLmdvYnJpZWxAaW50ZWwuY29tLGtlaXRoLndpbGVzQGludGVsLmNvbSxkb3VjZXR0ZUBidS5lZHUsZGV2QGRwZGsub3JnLHFpYW9iaW5mQGJ1LmVkdSx5aXBlbmcxLndhbmdAaW50ZWwuY29tLEhvbm5hcHBhLk5hZ2FyYWhhbGxpQGFybS5jb20= Feedback-ID: MjAxODA4Mjc=:bWljaGVsQGRpZ2lyYXRpLmNvbS5icg==:ZGlnaXJhdGkuY29tLmJy:k8networks X-Mailman-Approved-At: Tue, 28 Aug 2018 10:10:33 +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: Mon, 27 Aug 2018 18:27:12 -0000 On 08/26/2018 11:12 PM, Honnappa Nagarahalli wrote: > On 08/23/2018 08:33 PM, Wang, Yipeng1 wrote: >> I think with Honnappa suggested "uint32_t* next", we may need a little >> bit tricks to make it work with the extra linked list. >> The performance may not be optimal though comparing to your original approach. >> Is this important to your use case? > > It is. We are developing a DDoS protection system, and have chosen DPDK because it was the fastest framework in the evaluations we considered. We need to find the conflicting entries when a critical flow table of our system is overloaded due to an ongoing attack, so the more efficient we can evaluate the merits of an incoming flow against the conflicting flows already in the table, the higher the chances we find the flows that should be in the flow table. > > We've compromised with Honnappa under the understanding that once the underlying algorithm changes, there would be a review of the interface since even rte_hash_iterate() may be affected. I still think that the v2 we proposed is the best approach here because it isolates the interface from the underlying algorithm. > > My only concern was to do with keeping the interfaces across APIs consistent. I am fine with changing 'uint32_t *next' as long as we change 'rte_hash_iterate' API as well. We'll patch rte_hash_iterate() as well in v3. [ ]'s Michel Machado