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:34, Jan Viktorin wrote:
> On Thu, 5 Aug 2021 16:29:50 +0200
> "Medvedkin, Vladimir" <vladimir.medvedkin@intel.com> wrote:
> 
>> 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.
> 
> But reflecting the changes is sometimes really more difficult than just
> rebuilding from scratch.
> 

Why? Could you provide an example?

>>
>> 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.
> 

In this case you'll only have a single rib embedded into the fib

>> 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?
> 

Yes

> Jan
> 
>>
>>>>   
>>>>>>
>>>>>>
>>>>>> 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