From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Richardson Subject: Re: [RFC] Add RIB library Date: Mon, 14 Aug 2017 11:51:56 +0100 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 Cc: dev@dpdk.org To: Medvedkin Vladimir 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) Content-Disposition: inline In-Reply-To: <1499801585-10031-1-git-send-email-medvedkinv@gmail.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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