On Thu, 5 Aug 2021 16:29:50 +0200 "Medvedkin, Vladimir" <vladimir.medved...@intel.com> wrote:
> On 05/08/2021 16:07, Jan Viktorin wrote: > > On Thu, 5 Aug 2021 15:57:14 +0200 > > "Medvedkin, Vladimir" <vladimir.medved...@intel.com> wrote: > > > >> On 05/08/2021 15:32, Jan Viktorin wrote: > >>> On Thu, 5 Aug 2021 15:27:15 +0200 > >>> "Medvedkin, Vladimir" <vladimir.medved...@intel.com> 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 <vladimir.medved...@intel.com> 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 > >>>>>> <vladimir.medved...@intel.com> --- > >>>>>> 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. > >>>> > >>> > >> > > >
