On 05/08/2021 16:34, Jan Viktorin wrote:
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.
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.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.
--
Regards,
Vladimir
