From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id CD98A374F for ; Mon, 29 May 2017 11:30:12 +0200 (CEST) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga105.fm.intel.com with ESMTP; 29 May 2017 02:30:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,413,1491289200"; d="scan'208";a="267623857" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.42]) by fmsmga004.fm.intel.com with SMTP; 29 May 2017 02:30:09 -0700 Received: by (sSMTP sendmail emulation); Mon, 29 May 2017 10:30:09 +0100 Date: Mon, 29 May 2017 10:30:09 +0100 From: Bruce Richardson To: cs5120282@cse.iitd.ac.in Cc: dev@dpdk.org, cristian.dumitrescu@intel.com Message-ID: <20170529093008.GB32120@bricha3-MOBL3.ger.corp.intel.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.8.1 (2017-04-11) Subject: Re: [dpdk-dev] Why DPDK is not using compressed TRIE for LPM6? 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, 29 May 2017 09:30:13 -0000 On Sat, May 27, 2017 at 12:34:57AM +0530, Atul Shree wrote: > Hello All, > > I was doing some experiments related to LPM6 look up and I have added 20K > entries in the table. By looking at the rte_lpm6_lookup() code I found an > opportunity to compress the TRIE and there is a significant improvement > after compression. > Although I'm maintainer for LPM library, I'm not the original author of the LPM6 code. However, I'll give my thoughts here. Adding Cristian D. on CC as he was involved in the original implementation, IIRC. > Here are my questions: > Q1: Why DPDK is not doing the compression? It's probably not a deliberate omission, more likely that nobody has done it. > Q2. In the worst case the table will behave like an uncompressed TRIE and > in other cases, there is a scope of improvement. Is it worth doing? > If there is improvement in the normal case, with the worst-case perf being no worse, it sounds like it may be worth doing. Feel free to submit patches for evaluation on the list. Regards, /Bruce