From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f170.google.com (mail-qk0-f170.google.com [209.85.220.170]) by dpdk.org (Postfix) with ESMTP id C96D9231E for ; Wed, 12 Jul 2017 01:13:09 +0200 (CEST) Received: by mail-qk0-f170.google.com with SMTP id v17so40244qka.3 for ; Tue, 11 Jul 2017 16:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AdxxH+/Io7SZHzKmCWVsmtWv9Zni5p2Lfyt7Q7iMBvo=; b=nyMJWBGaAalCs542HJ435puiY0iIVIJPtGXiBQ2JzxKexeURaV3XpDjAfBf8WpsdcK XTjcL+6Dwz5Bt7x+5IC1+nKT3ahszXI763TRZltHBeqGSbI6F22oAgjwcMTwmDXSlsuf tGDruIZI/VeJQ36swLBqqd2wF4sFSPTHaERPSYvqvKL1dYCT3FbFqPYTebOw3dAxMud2 +VUgLlfUJcCsivTaV9DszxNQL4skKniJDUxZPe1c6WMkedM91t1kKfS5t5I+0zhG01jr zRgWPZy9epMI11LUK5wW2vKFE3AKUyzLO3sFodCU/AyWFAgbO/f2CIafunNPwejn+JFq rOdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AdxxH+/Io7SZHzKmCWVsmtWv9Zni5p2Lfyt7Q7iMBvo=; b=ACB48IUqhbneR+NvruQJ3mqor/7TmecuRbm/+8bbAykEV9w6WeSt9qsHIxKKB9XxFJ BI/2xcqorUq77MbR7TIEkvmBPENqq5Oik5tsPT1urfspbQDGkV2di6ZCIA9kDkwALMXZ uj13xnWEr38MRQaFSSZikxMMjYJT0hnxXBDVt0XuSGy61sqLLySWVGlvXarAEP/FxVhg 1HPEZl8E4OoFE5QT0yK6vykNB0Q091fZDiekdVVEiQMdU3wSFme9qOImSjUgtwt6Z7IK x5Tx+cVWiP/uYKwJDCNJVGa62SdVDXZyVBPzJOYsFVmuWE3fR9WcXlGhHc3s7TwBsrjW xP5g== X-Gm-Message-State: AIVw110+z029fOT4DQVMWt4ZqnqkmbDfU40pyKMo+IKxl3Y4FiqBHWFi YNsb9fWzudqJMc7wdBwbP/zGP492ETO/ X-Received: by 10.55.60.13 with SMTP id j13mr3088735qka.71.1499814789184; Tue, 11 Jul 2017 16:13:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.37.3 with HTTP; Tue, 11 Jul 2017 16:13:08 -0700 (PDT) In-Reply-To: <20170711133143.77f02240@xeon-e3> References: <1499801585-10031-1-git-send-email-medvedkinv@gmail.com> <20170711133143.77f02240@xeon-e3> From: Vladimir Medvedkin Date: Wed, 12 Jul 2017 02:13:08 +0300 Message-ID: To: Stephen Hemminger Cc: "dev@dpdk.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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: Tue, 11 Jul 2017 23:13:10 -0000 Actually that is vendor specific. For example Juniper takes all route information from protocol specific tables and compiles it in rib (yes, they call it rib) so-called inet.0 (for ipv4 default VRF). In general RIB contains control plane information and is used for control plane purpose such as fib modification and for example showing route information in CLI. FIB is used on dataplane only to make forwarding decision. Actually with this new library you can keep information about all particular route sources and all protocol specific information. For example I have in my rib 10.0.0.0/8 *[Static/5] 42w2d 10:58:02 > to 10.201.254.1 via ae1.996 [Static/5] 35w6d 05:39:47 Discard [OSPF/150] 3w0d 07:49:33, metric 15, tag 0 > to 1.1.1.1 via ae3.0 [BGP/170] 07:17:26, localpref 100, from 1.1.2.1 AS path: I, validation-state: unverified > to 1.1.2.2 via ae1.879, label-switched-path M9-OS1 [BGP/170] 2w1d 01:13:34, localpref 100, from 1.1.3.1 AS path: I, validation-state: unverified > to 1.1.3.2 via ae1.878, label-switched-path M9-OS0 [BGP/170] 2w0d 02:54:47, localpref 100, from 1.1.4.1 AS path: I, validation-state: unverified > to 1.1.4.2 via ae2.811, label-switched-path M9-KR0 So you have only one struct rte_rib_v4_node for prefix 10.0.0.0/8 that contains app specific information like struct my_app_static_ext { int admin_dist; time_t time; uint64_t nh_id; } struct my_app_ospf_ext { int admin_dist; time_t time; uint64_t nh_id; int metric; int type; } struct my_app_bgp_ext { int admin_dist; time_t time; uint64_t nh_id uint32_t source; int med; int localpref; char * as_path; char* community; } union my_app_proto_ext { struct my_app_static_ext; struct my_app_ospf_ext; struct my_app_bgp_ext; } struct my_app_ext { struct my_app_ext *next; int type; union my_app_proto_ext; } in it's .ext field. In this way you'll keep information about all routes. 2017-07-11 23:31 GMT+03:00 Stephen Hemminger : > On Tue, 11 Jul 2017 19:33:04 +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 > > > > config/common_base | 6 + > > doc/api/doxy-api.conf | 1 + > > lib/Makefile | 2 + > > lib/librte_rib/Makefile | 43 ++++ > > lib/librte_rib/rte_dir24_8.c | 411 ++++++++++++++++++++++++++++++ > +++++++++ > > lib/librte_rib/rte_dir24_8.h | 144 ++++++++++++++ > > lib/librte_rib/rte_rib.c | 454 ++++++++++++++++++++++++++++++ > +++++++++++++ > > lib/librte_rib/rte_rib.h | 260 +++++++++++++++++++++++++ > > 8 files changed, 1321 insertions(+) > > create mode 100644 lib/librte_rib/Makefile > > create mode 100644 lib/librte_rib/rte_dir24_8.c > > create mode 100644 lib/librte_rib/rte_dir24_8.h > > create mode 100644 lib/librte_rib/rte_rib.c > > create mode 100644 lib/librte_rib/rte_rib.h > > > > In network paralance a RIB is usually a full route table and FIB is the > forwarding > table in use. You probably don't want to call this a RIB. It looks more > like an > abstraction above FIB. > > > https://networkengineering.stackexchange.com/questions/ > 38588/rib-vs-fib-differences > http://aftabsiddiqui.com/index.php/ip-routing-table- > rib-and-forwarding-table-fib/ > -- Regards, Vladimir