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 1BD637D3E for ; Mon, 14 Aug 2017 12:52:06 +0200 (CEST) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Aug 2017 03:51:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,372,1498546800"; d="scan'208";a="137159622" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.24]) by orsmga005.jf.intel.com with SMTP; 14 Aug 2017 03:51:57 -0700 Received: by (sSMTP sendmail emulation); Mon, 14 Aug 2017 11:51:56 +0100 Date: Mon, 14 Aug 2017 11:51:56 +0100 From: Bruce Richardson To: Medvedkin Vladimir Cc: dev@dpdk.org Message-ID: <20170814105156.GA8112@bricha3-MOBL3.ger.corp.intel.com> References: <1499801585-10031-1-git-send-email-medvedkinv@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1499801585-10031-1-git-send-email-medvedkinv@gmail.com> Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.8.3 (2017-05-23) Subject: Re: [dpdk-dev] [RFC] Add RIB library 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, 14 Aug 2017 10:52:07 -0000 On Tue, Jul 11, 2017 at 07:33:04PM +0000, Medvedkin Vladimir wrote: > Hi, > > I want to introduce new library for ip routing lookup that have some advantages > over current LPM library. In short: > - Increases the speed of control plane operations against lpm such as > adding/deleting routes > - Adds abstraction from dataplane algorythms, so it is possible to add > different ip route lookup algorythms such as DXR/poptrie/lpc-trie/etc > in addition to current dir24_8 > - It is possible to keep user defined application specific additional > information in struct rte_rib_v4_node which represents route entry. > It can be next hop/set of next hops (i.e. active and feasible), > pointers to link rte_rib_v4_node based on some criteria (i.e. next_hop), > plenty of additional control plane information. > - For dir24_8 implementation it is possible to remove rte_lpm_tbl_entry.depth > field that helps to save 6 bits. > - Also new dir24_8 implementation supports different next_hop sizes > (1/2/4/8 bytes per next hop) > > It would be nice to hear your opinion. The draft is below. > > Medvedkin Vladimir (1): > lib/rib: Add Routing Information Base library > On reading this patch and then having discussion with you offline, it appears there are two major new elements in this patchset: 1. a re-implementation of LPM, with the major advantage of having a flexible data-size 2. a separate control plane structure that is designed to fit on top off possibly multiple lookup structures for the data plane Is this correct? For the first part, I don't think we should carry about two separate LPM implementations, but rather look to take the improvements in your version back into the existing lib. [Or else replace the existing one, but I prefer pulling the new stuff into it, so as to keep backward compatibility] For the second part, perhaps you could expand a bit more on the thought here, and explain what all different data plane implementations would fit under it. Would, for instance a hash-lookup work? In that case, what would the data plane APIs be, and the control plane ones. Thanks, /Bruce