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

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

[Vladimir Medvedkin]

This patch announces the experimental tag removal of all rib APIs,
which have been experimental for 2 years.
API will be promoted to stable in DPDK 21.11

Signed-off-by: Vladimir Medvedkin <vladimir.medvedkin@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 f4a4d00..afb599a 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -193,3 +193,5 @@ Deprecation Notices
   reserved bytes to 2 (from 3), and use 1 byte to indicate warnings and other
   information from the crypto/security operation. This field will be used to
   communicate events such as soft expiry with IPsec in lookaside mode.
+
+* rib: The ``rib`` library will be promoted from experimental to stable.
-- 
2.7.4

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

[Vladimir Medvedkin]

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

Signed-off-by: Vladimir Medvedkin <vladimir.medvedkin@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.
-- 
2.7.4

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

[Walsh, Conor]

> 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
> 
> Signed-off-by: Vladimir Medvedkin <vladimir.medvedkin@intel.com>
> ---
>  doc/guides/rel_notes/deprecation.rst | 2 ++
>  1 file changed, 2 insertions(+)

Acked-by: Conor Walsh <conor.walsh@intel.com>

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

[Jerin Jacob]

On Thu, Aug 5, 2021 at 7:23 PM Walsh, Conor <conor.walsh@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
> >
> > Signed-off-by: Vladimir Medvedkin <vladimir.medvedkin@intel.com>
> > ---
> >  doc/guides/rel_notes/deprecation.rst | 2 ++
> >  1 file changed, 2 insertions(+)
>
> Acked-by: Conor Walsh <conor.walsh@intel.com>

Acked-by: Jerin Jacob <jerinj@marvell.com>

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

[Jerin Jacob]

On Thu, Aug 5, 2021 at 4:56 PM Vladimir Medvedkin
<vladimir.medvedkin@intel.com> wrote:
>
> This patch announces the experimental tag removal of all rib APIs,
> which have been experimental for 2 years.
> API will be promoted to stable in DPDK 21.11
>
> Signed-off-by: Vladimir Medvedkin <vladimir.medvedkin@intel.com>

Acked-by: Jerin Jacob <jerinj@marvell.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 f4a4d00..afb599a 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -193,3 +193,5 @@ Deprecation Notices
>    reserved bytes to 2 (from 3), and use 1 byte to indicate warnings and other
>    information from the crypto/security operation. This field will be used to
>    communicate events such as soft expiry with IPsec in lookaside mode.
> +
> +* rib: The ``rib`` library will be promoted from experimental to stable.
> --
> 2.7.4
>

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

[David Marchand]

On Thu, Aug 5, 2021 at 1:26 PM Vladimir Medvedkin
<vladimir.medvedkin@intel.com> wrote:
>
> This patch announces the experimental tag removal of all rib APIs,
> which have been experimental for 2 years.
> API will be promoted to stable in DPDK 21.11
>
> Signed-off-by: Vladimir Medvedkin <vladimir.medvedkin@intel.com>

Either this series was missed or judged unneeded during 21.08.
In any case, the API promotion to stable will be merged in 21.11.

Marked series as not applicable.


-- 
David Marchand

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

[Medvedkin, Vladimir]

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.


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

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

[Jan Viktorin]

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

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

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

[Medvedkin, Vladimir]

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?

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

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

[Jan Viktorin]

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

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

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

[Medvedkin, Vladimir]

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

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

[Jan Viktorin]

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.

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

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

[Medvedkin, Vladimir]

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