From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id E1DB5A0C40; Thu, 5 Aug 2021 16:34:25 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7D37140143; Thu, 5 Aug 2021 16:34:25 +0200 (CEST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by mails.dpdk.org (Postfix) with ESMTP id E920D40040 for ; Thu, 5 Aug 2021 16:34:23 +0200 (CEST) Received: from coaster.localdomain (unknown [IPv6:2001:67c:1220:80e:a9:edd0:2e93:a6c4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id A38A640006D; Thu, 5 Aug 2021 16:34:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2-2020; t=1628174063; bh=4Hw4i0KHNub15YYXoRpqLkR6kQ+MWje4SKy+NUR8BC0=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=PBY9E8sw0B0bIGuR36jvDPQsZ8Z+95w1V2N7mBpeOH2m2mEsOiFSPSRvbpdlq3SkD Bd04UMFGuavKF3z9JyRAAPNHFh+xI+pK3x/2Oluyz3uJ0vVRNYbjEnTkwdLRVkNGkx zc39pMzN/bVuTIYQV4zIe36Uhk1BgfsHuwRWZM4jGoXaaDB5ZFwMzAeEAtlGlOlSe8 c942+PXcDrLWhX44S0P133ufgrIy1BQgTo0A5lG+wQ8V9mTx5hf0a9Cqr8g2IMFGYy tNN7NS5wp6vq1rMk5yL2vaTOAIgc+x2BDJZrFmtNnV6MJbwuM72GDa7+cdetrpptq+ cU5tk6Y3o+w8w== Date: Thu, 5 Aug 2021 16:34:21 +0200 From: Jan Viktorin To: "Medvedkin, Vladimir" Cc: "dev@dpdk.org" Message-ID: <20210805163421.2641da2a@coaster.localdomain> In-Reply-To: <22b94f92-c7f5-f1de-6d24-243ed6e0c90b@intel.com> References: <20210805151451.59932409@coaster.localdomain> <32cb2d90-2a08-ec06-0c71-031b6187c472@intel.com> <20210805153201.0f6a1dee@coaster.localdomain> <4369f1c3-c9f6-693a-5b21-1a5a4774478d@intel.com> <20210805160720.401f877c@coaster.localdomain> <22b94f92-c7f5-f1de-6d24-243ed6e0c90b@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 2/2] fib: announce experimental tag removal of the fib API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list 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 Thu, 5 Aug 2021 16:29:50 +0200 "Medvedkin, Vladimir" wrote: > On 05/08/2021 16:07, Jan Viktorin wrote: > > On Thu, 5 Aug 2021 15:57:14 +0200 > > "Medvedkin, Vladimir" wrote: > > > >> On 05/08/2021 15:32, Jan Viktorin wrote: > >>> On Thu, 5 Aug 2021 15:27:15 +0200 > >>> "Medvedkin, Vladimir" wrote: > >>> > >>>> Hi Jan, > >>>> > >>>> The RIB is always used as a control plane struct intended to > >>>> maintain the correct content of the dataplane struct, such as > >>>> DIR24_8 for example. So it is always used on _add()/_delete(). > >>>> For simplicity you can consider it as an LPM's rule_info. But > >>>> instead of keeping routes in a plane array as it is in LPM, FIB > >>>> uses RIB which is more suitable binary tree. > >>> > >>> OK. I thought that I can have a single RIB, use it for maintaining > >>> routes and based on this single RIB, I can build a FIB for the > >>> data plane. And when the single RIB is updated (which can take > >>> quite a lot of time) I build a new FIB and locklessly give it to > >>> the dataplane. Such approach is not considered? > >>> > >>> Jan > >>> > >> > >> I'm not sure I understood completely your use case. Do you want to > >> rebuild the entire FIB from scratch every time the RIB changes? > > > > The idea was to maintain a single RIB and two FIBs. One FIB is > > active and under heavy load and when a route change arrives, it is > > first written to RIB. When RIB is ready, it is used to quickly > > construct/update the second inactive FIB. Then I swap with the > > current active FIB. The old one can be edited/updated/recreated and > > new one is active. > > > > I've got one place where all routes are placed (RIB). And two FIBs > > that contain only routes that are relevant. (Well, yes, not all > > routes in RIB might be relevant, this depends on other conditions.) > > > > Jan > > > > This technique is used for data structures that do not support > incremental updates. However FIB supports incremental updates. > > You can keep a separate rib struct and reflect changes to the fib. But reflecting the changes is sometimes really more difficult than just rebuilding from scratch. > > Also, using rte_fib_get_rib() you can get the corresponding RIB > struct and work with it directly using rib API. However you need to But than I've got two RIBs that I have to keep in sync with each other which is quite difficult. > be cautious, all adding/deletion and next hop changing must be done > using fib API. Because, otherwise the DIR24_8 is not in sync, right? Jan > > >> > >>>> > >>>> > >>>> On 05/08/2021 15:14, Jan Viktorin wrote: > >>>>> On Thu, 5 Aug 2021 15:08:13 +0200 > >>>>> Vladimir Medvedkin wrote: > >>>>> > >>>>>> This patch announces the experimental tag removal of all fib > >>>>>> APIs, which have been experimental for 2 years. > >>>>>> API will be promoted to stable in DPDK 21.11 > >>>>> > >>>>> Hi Vladimir, > >>>>> > >>>>> I have a question related to FIB. I am just learning how to use > >>>>> it and I found that each FIB always creates a new RIB > >>>>> internally. There is no doc about this topic... > >>>>> > >>>>> If I understand correctly, the underlying RIB is only used when > >>>>> dummy_lookup() and dummy_modify() are used. But they are only > >>>>> used when the configured mode is RTE_FIB_DUMMY. Is there any > >>>>> reason to create the RIB with RTE_FIB_DIR24_8? > >>>>> > >>>>> The issue with this is that each RIB allocates a new mempool > >>>>> internally which can waste quite a lot of never used memory that > >>>>> would be unused with DIR24_8 implementation. > >>>>> > >>>>> Regards > >>>>> Jan > >>>>> > >>>>>> > >>>>>> > >>>>>> Signed-off-by: Vladimir Medvedkin > >>>>>> --- > >>>>>> doc/guides/rel_notes/deprecation.rst | 2 ++ > >>>>>> 1 file changed, 2 insertions(+) > >>>>>> > >>>>>> diff --git a/doc/guides/rel_notes/deprecation.rst > >>>>>> b/doc/guides/rel_notes/deprecation.rst > >>>>>> index afb599a..58826a8 100644 > >>>>>> --- a/doc/guides/rel_notes/deprecation.rst > >>>>>> +++ b/doc/guides/rel_notes/deprecation.rst > >>>>>> @@ -195,3 +195,5 @@ Deprecation Notices > >>>>>> communicate events such as soft expiry with IPsec in > >>>>>> lookaside mode. > >>>>>> * rib: The ``rib`` library will be promoted from > >>>>>> experimental to stable. + > >>>>>> +* fib: The ``fib`` library will be promoted from experimental > >>>>>> to stable. > >>>> > >>> > >> > > >