From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 30CCB2BFF for ; Wed, 22 Feb 2017 16:23:54 +0100 (CET) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Feb 2017 07:23:53 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,194,1484035200"; d="scan'208";a="61142406" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.61]) by orsmga004.jf.intel.com with SMTP; 22 Feb 2017 07:23:51 -0800 Received: by (sSMTP sendmail emulation); Wed, 22 Feb 2017 15:23:51 +0000 Date: Wed, 22 Feb 2017 15:23:51 +0000 From: Bruce Richardson To: Nikita Kozlov Cc: dev@dpdk.org Message-ID: <20170222152350.GA18956@bricha3-MOBL3.ger.corp.intel.com> References: <1465433634-6667-1-git-send-email-nikita@elyzion.net> <20160824225908.16078-1-nikita@elyzion.net> 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.7.2 (2016-11-26) Subject: Re: [dpdk-dev] [PATCH v2 0/2] lpm6: speed improvement on delete rule 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, 22 Feb 2017 15:23:55 -0000 On Fri, Sep 16, 2016 at 03:15:01PM +0200, Nikita Kozlov wrote: > On 08/25/2016 00:59, Nikita Kozlov wrote: > > This serie of pathes focus on improving the speed of deleting rules in lpm6. > > > > It also contains some other improvement like having a dynamic number of > > rules in lpm6 and increasing the lpm6 nexthop size to 16bit for matching > > the nexthop size in lpm4. > > > > The performances improvement can be seen by running test_lpm6_perf but > > because of the limited number of rules added (1000) the improvement seen is > > just about a x10 with this test. > > > > For testing it further we have tested it with a full ipv6 bgp view which > > represent 29296 routes in our test: > > * With the dpdk 16.04 it tooks an average of 8.46095e+09 cycles to delete a rule > > (calculated with mesuring rte_rdtsc before and after the delete, the > > average is calculated by the first 10 delete, it represents several > > seconds on a E5-2650 v2) > > * With the patch it tooks 10077.1 cycles (same number of deleted rules, > > same machine, same rules inserted) for the same test. > > > > This patch was written in collaboration with Baptiste Daroussin from Gandi. > > > > Changes since V1: > > - use system bsd-tree.h > > - fix a bug when valid_group field was overwritten > > > > Nikita Kozlov (2): > > lpm6: speed inmprovement on delete rule > > test_lpm6: make test_lpm6* compatible with the new rte_lpm6.c lib > > > > app/test/test_lpm6.c | 244 +++++-------- > > app/test/test_lpm6_perf.c | 6 +- > > lib/librte_lpm/Makefile | 2 +- > > lib/librte_lpm/rte_lpm6.c | 626 +++++++++++++++++++++++++--------- > > lib/librte_lpm/rte_lpm6.h | 50 ++- > > lib/librte_lpm/rte_lpm_version.map | 12 + > > lib/librte_table/rte_table_lpm_ipv6.c | 7 +- > > 7 files changed, 609 insertions(+), 338 deletions(-) > > > Hello, > If someone have some time, I feel that this patch needs some polishing > so any comments on the code are more than welcome, even if they are not > directly related to the lpm part itself. > > thanks. Resurrecting this old thread, having spotted the patches in patchwork. I've run some before/after tests with lpm6_perf_autotest. The results I get show the delete performance improving ~33x with this patch applied. (That's 33x, not 33%!). That's less than the numbers claimed above for a real-world case, but still very, very impressive. I see some regression with the add cycles, but *only* about 20% or so. I can live with that for the improvement in delete speed. The big issue I spotted with these two patches is that they need to be merged together, since patch 2 fixes the compile errors introduced with patch 1. Once the patches are combined then that combined patch should ideally be split into smaller onces for the individual changes made: i.e. any changes not part of the rework of delete, should be in different patches, but the repo should compile after each patch has been applied. I note also, that there is another patches outstanding on DPDK to increase the next-hop size to 21 bits. That patch conflicts with this one, but it probably should go in first as it's a smaller simpler change, and this set needs a revision. So, any plans for a V3 of this set? Regards, /Bruce