Re: [dpdk-dev] [PATCH 2/2] fib: announce experimental tag removal of the fib API

["Medvedkin, Vladimir" <vladimir.medvedkin@intel.com>]

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

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 be 
cautious, all adding/deletion and next hop changing must be done using 
fib API.

>>
>>>>
>>>>
>>>> On 05/08/2021 15:14, Jan Viktorin wrote:
>>>>> On Thu, 5 Aug 2021 15:08:13 +0200
>>>>> Vladimir Medvedkin <vladimir.medvedkin@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.
>>>>   
>>>    
>>
> 

-- 
Regards,
Vladimir