From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id EDB0468AF for ; Tue, 23 Sep 2014 04:45:15 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 22 Sep 2014 19:51:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,576,1406617200"; d="scan'208,217";a="603772727" Received: from sgarg4-mobl2.amr.corp.intel.com (HELO [10.254.104.116]) ([10.254.104.116]) by fmsmga002.fm.intel.com with ESMTP; 22 Sep 2014 19:42:34 -0700 Message-ID: <5420DE12.2050508@intel.com> Date: Mon, 22 Sep 2014 19:42:26 -0700 From: "Venkatesan, Venky" User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dev@dpdk.org References: <20140923013356.GA26558@mhcomputing.net> In-Reply-To: <20140923013356.GA26558@mhcomputing.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] LRU using DPDK 1.7 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 02:45:16 -0000 On 9/22/2014 6:33 PM, Matthew Hall wrote: > On Tue, Sep 23, 2014 at 01:08:21AM +0000, Saha, Avik (AWS) wrote: >> I was wondering if there is way to use the rte_table_hash_lru without >> building a pipeline - Basically using the same hash table like functionality >> of add, delete and lookup without setting up a pipeline and connect it to >> ports etc. > I've been finding that rte_hash is designed only for some very specialized > purposes. It doesn't work well if you use unexpected sizes of keys or want > behavior that isn't precisely doing what the designers of the hash used it > for... it's not very general-purpose. Yes, it isn't very general purpose as of now (arbitrary key sizes, failure path on add if bucket is full etc.). It was designed to be a tuple matcher, albeit for a much different performance level than what we have driven the DPDK to at present. That said, the structure of this is something that I expect that we will change to make much more flexible, and have a few ideas I'm exploring along that line. What would be helpful is start adding to that list of limitations from your perspective so that we can address as much of that with one patch set. > > I did try to point out one example of the issue but I didn't get much response > yet to my questions about its limitations and whether a more general-purpose > table was available, or at least some discussion what rte_hash is for and what > it's not for. > > Matthew. I missed the original email you refer to - I'll dig that up as well from the archives. Regards, -Venky