From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com [209.85.215.48]) by dpdk.org (Postfix) with ESMTP id 883C12C5A for ; Tue, 19 Apr 2016 22:46:56 +0200 (CEST) Received: by mail-lf0-f48.google.com with SMTP id g184so28519303lfb.3 for ; Tue, 19 Apr 2016 13:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=gLDnsopz2AsWWAO6hpItq51hRoLdurD4eGc96VsBnVc=; b=DqH13U2QfWQ3agkhkCr5yrQn9NOeSX4KaGMbrqcEcbo30Q24Z9q6O31aDTU9LoUF0m iyITTWthvyInBUAzXRZf+1bmrMnVNpAceu9ppie1UlU6bdYA9A6gy9mJFoGgDswIrkB8 CFpnsaXTnys5y0jeW9sF3p1eXE2xRYhYwp85f7msN+KlMhPnKyaqMjdiX+shWUAjIKsC xCfpyHPTEruq0iDz+h5jTL8E7jRDV+qbjYP7OAMJSsAFSjKqL0mHmXXCqb8BGKN1UQ1u l8q6eRc2HvbtwatqRzgPSC9Db6hhiwU8Hnf2iRVGNefzLCo2jkw+QeZd9ioeqxV8xW6k zz/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=gLDnsopz2AsWWAO6hpItq51hRoLdurD4eGc96VsBnVc=; b=cSDjXq0miXWO2n1ILHdrqHlpJHKlx9PsBPLsGQRktvBChtM0xAVDYC6AWIhhwwKeFF JzKUC57yv/Tvqi99yU0xulXi+at3rYhfg53Objrp0yy+cAyy2kg0VCjNyhSfDh7h9XZt ZQhGFjiRYCj1RV5cbQJkE9Dq+vbWYKdE4dKggATfT4NLJw2fTyt5VrqYrZcy6HO+zXOX xtpt0Bl76eQpxDYQjaxwCCPCiSa/meEkTWZcl0T+zoSErAV77QMEHzzYWFq1iS+HiAhl B5BUm0GA5UOrJ+GmF6FXvClxcdGw3ePap9ci3+4JWCVIxLm78b4MhjipnQqgLODU+4Nn Ek9Q== X-Gm-Message-State: AOPr4FUe7nHw5MZiAQwfThECD4KnGZmAFwx6oNoDxHpLPhojBDzLEx0A024iQyxRfju+K7ZEvonj9EyQEXcaQw== MIME-Version: 1.0 X-Received: by 10.112.17.98 with SMTP id n2mr1985821lbd.47.1461098816187; Tue, 19 Apr 2016 13:46:56 -0700 (PDT) Received: by 10.114.182.166 with HTTP; Tue, 19 Apr 2016 13:46:56 -0700 (PDT) In-Reply-To: <20160419084640.52235b05@xeon-e3> References: <20160419084640.52235b05@xeon-e3> Date: Tue, 19 Apr 2016 23:46:56 +0300 Message-ID: From: Vladimir Medvedkin To: Stephen Hemminger Cc: =?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCa0LjRgdC10LvQtdCy?= , "dev@dpdk.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] perfomance of rte_lpm rule subsystem 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, 19 Apr 2016 20:46:56 -0000 Hi Alexander, Why next_hop is 64 bit long? 2016-04-19 18:46 GMT+03:00 Stephen Hemminger : > On Tue, 19 Apr 2016 14:11:11 +0300 > =D0=90=D0=BB=D0=B5=D0=BA=D1=81=D0=B0=D0=BD=D0=B4=D1=80 =D0=9A=D0=B8=D1=81= =D0=B5=D0=BB=D0=B5=D0=B2 wrote: > > > Hi. > > > > 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 > "rule" > > subsystem. > > > > 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 > else > > I would like to discuss my patch. > > The patch also include changes that make next_hop 64 bit, so please jus= t > > ignore them. The rule changes are in the following > > functions only: > > > > rte_lpm2_create > > > > rule_find > > rule_add > > rule_delete > > find_previous_rule > > delete_depth_small > > delete_depth_big > > > > rte_lpm2_add > > rte_lpm2_delete > > rte_lpm2_is_rule_present > > rte_lpm2_delete_all > > > > We forked LPM back several versions ago. > I sent the patches to use BSD red-black tree for rules but the patches we= re > ignored. mostly because it broke ABI. > --=20 Regards, Vladimir