From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Kiselev Subject: Re: perfomance of rte_lpm rule subsystem Date: Wed, 20 Apr 2016 08:06:44 +0300 Message-ID: References: <20160419084640.52235b05@xeon-e3> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable To: dev@dpdk.org Return-path: Received: from mail-lf0-f68.google.com (mail-lf0-f68.google.com [209.85.215.68]) by dpdk.org (Postfix) with ESMTP id 263182C0C for ; Wed, 20 Apr 2016 07:06:46 +0200 (CEST) Received: by mail-lf0-f68.google.com with SMTP id j10so4569342lfg.3 for ; Tue, 19 Apr 2016 22:06:46 -0700 (PDT) Received: from [10.244.220.199] ([31.173.80.226]) by smtp.gmail.com with ESMTPSA id i204sm707272lfg.47.2016.04.19.22.06.44 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Apr 2016 22:06:44 -0700 (PDT) In-Reply-To: <20160419084640.52235b05@xeon-e3> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" I just realizied that my patch could be confusing. I want to emphasize that i= t contains two completly different and independent set of changes. One is ne= w rule subsystem and the other is 64 bit next hop. Maybe I should've prepare= d a patch with only rule changes, but I wanted to discuss fist and if there w= ould be interest spend some time and make the final patch containing only ru= le changes.=20 Please ignore the next hop changes. They have nothing to do with rule subsys= tem changes. The rule changes don't need new next hop and I don't want 64 bi= t next hop to be part of dpdk. >> Hi. >>=20 >> Doing some test with rte_lpm (adding/deleting bgp full table rules) I >> noticed that >> rule subsystem is very slow even considering that probably it was never >> designed for using >> in a data forwarding plane. So I want to propose some changes to the "rul= e" >> subsystem. >>=20 >> I reimplemented rule part ot the lib using rte_hash, and perfomance of >> adding/deleted routes have increased dramatically. >> If increasing speed of adding deleting routes makes sence for anybody els= e >> I would like to discuss my patch. >> The patch also include changes that make next_hop 64 bit, so please just >> ignore them. The rule changes are in the following >> functions only: >>=20 >> rte_lpm2_create >>=20 >> rule_find >> rule_add >> rule_delete >> find_previous_rule >> delete_depth_small >> delete_depth_big >>=20 >> rte_lpm2_add >> rte_lpm2_delete >> rte_lpm2_is_rule_present >> rte_lpm2_delete_all