aboutsummaryrefslogtreecommitdiffstats
path: root/docs/gettingstarted/developers/fib20/dataplane.rst
diff options
context:
space:
mode:
Diffstat (limited to 'docs/gettingstarted/developers/fib20/dataplane.rst')
-rw-r--r--docs/gettingstarted/developers/fib20/dataplane.rst37
1 files changed, 19 insertions, 18 deletions
diff --git a/docs/gettingstarted/developers/fib20/dataplane.rst b/docs/gettingstarted/developers/fib20/dataplane.rst
index a9e2bf27d69..34886e18a44 100644
--- a/docs/gettingstarted/developers/fib20/dataplane.rst
+++ b/docs/gettingstarted/developers/fib20/dataplane.rst
@@ -71,24 +71,25 @@ The diagrams above show that for any given route the full data-plane graph is
known before any packet arrives. If that graph is composed of n objects, then the
packet will visit n nodes and thus incur a forwarding cost of approximately n
times the graph node cost. This could be reduced if the graph were *collapsed*
-into a single DPO and associated node. However, collapsing a graph removes the
-indirection objects that provide fast convergence (see section Fast Convergence). To
-collapse is then a trade-off between faster forwarding and fast convergence; VPP
-favours the latter.
-
-This DPO model effectively exists today but is informally defined. Presently the
-only object that is in the data-plane is the ip_adjacency_t, however, features
-(like ILA, OAM hop-by-hop, SR, MAP, etc) sub-type the adjacency. The member
-lookup_next_index is equivalent to defining a new sub-type. Adding to the
-existing union, or casting sub-type specific data into the opaque member, or
-even over the rewrite string (e.g. the new port range checker), is equivalent
-defining a new C-struct type. Fortunately, at this time, all these sub-types are
-smaller in memory than the ip_adjacency_t. It is now possible to dynamically
-register new adjacency sub-types with ip_register_adjacency() and provide a
-custom format function.
-
-In my opinion a strongly defined object model will be easier for contributors to
-understand, and more robust to implement.
+into fewer DPOs and nodes. There are two ways we might consider doing
+this:
+
+- write custom DPOs/nodes for combinded functions, e.g. pop MPLS label
+ and lookup in v4 table. This has the disadvantage that the number of
+ such nodes would be, well, combinatorial, and resolving a path via
+ a combined DPO would be more difficult as it would involve a
+ forward walk of the graph to determine what the combination
+ is. However, VPP power users might consider this option for a
+ limited set of their use cases where performance is truely king.
+- collapse multiple levels of load-balancing into one. For example,
+ if there were two levels of load-balancing each with two choices,
+ this could equally be represented by one level with 4 choices.
+
+In either case a disadvantage to collapsing the graph is that it
+removes the indirection objects that provide fast convergence (see
+section Fast Convergence). To collapse is then a trade-off between
+faster forwarding and fast convergence; VPP favours the latter.
+
.. rubric:: Footnotes: