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 EA655A0C40; Thu, 5 Aug 2021 16:07:22 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 781DE40143; Thu, 5 Aug 2021 16:07:22 +0200 (CEST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by mails.dpdk.org (Postfix) with ESMTP id D6CB240040 for ; Thu, 5 Aug 2021 16:07:20 +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 8066540006D; Thu, 5 Aug 2021 16:07:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2-2020; t=1628172440; bh=thDO/uufVGOAFWRi0/IdyHqWQ75k02RqbNOnpzhHSYY=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=XB/CYS/uLLAm5XZ7Ce8d47aQw+OAtMCHzxCrgVMtl6TG+hX+JSqzbQP/5yIibvRo/ dEe5ONHQrCSkqkA1xohfV1TEEddajCmRMG9U4KrhGgStZfgpN0oqbcOLz0r//gMBg8 YFfqBTRiwHNlbN2ywZF567zpS9QYfmwdN7k9hnUpm+aN5CZH9F1RH6k673Epob/uOz k1c3NoWRGVkA/QlCikJGzpEj0iFkRIF+FpRmZwsBfEwI64y3Q0rQMrfz3C40ta+7PY apVNuX+s5l+xNhpa6glwZql2vVU7Zow2Tc9nOtZpPSI9YAMFuk6HVp3Y8LEzedMLuS FW5Vddv9aGvKQ== Date: Thu, 5 Aug 2021 16:07:20 +0200 From: Jan Viktorin To: "Medvedkin, Vladimir" Cc: "dev@dpdk.org" Message-ID: <20210805160720.401f877c@coaster.localdomain> In-Reply-To: <4369f1c3-c9f6-693a-5b21-1a5a4774478d@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> 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 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 > > >> > >> > >> 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. > >> > > >