the actions to perform on the packet. Each object type has an associated VLIB
graph node. For a packet to forward walk the graph is therefore to move from one
VLIB node to the next, with each performing the required actions. This is the
-heart of the VPP model.
+heart of the VPP model.
The data-plane graph is composed of generic data-path objects (DPOs). A parent
DPO is identified by the tuple:{type,index,next_node}. The *next_node* parameter
not need to be read [#f17]_ whilst processing the child. Specialisations [#f18]_ of the DPO
perform distinct actions. The most common DPOs and briefly what they represent are:
-- Load-balance: a choice in an ECMP set.
+- Load-balance: a choice in an ECMP set.
- Adjacency: apply a rewrite and forward through an interface
- MPLS-label: impose an MPLS label.
- Lookup: perform another lookup in a different table.
Each *fib_entry_t* contributes it own *load_balance_t*, for three reasons;
-- The result of a lookup in a IPv[46] table is a single 32 bit unsigned integer. This is an index into a memory pool. Consequently the object type must be the same for each result. Some routes will need a load-balance and some will not, but to insert another object in the graph to represent this choice is a waste of cycles, so the load-balance object is always the result. If the route does not have ECMP, then the load-balance has only one choice.
+- The result of a lookup in a IPv[46] table is a single 32 bit unsigned integer. This is an index into a memory pool. Consequently the object type must be the same for each result. Some routes will need a load-balance and some will not, but to insert another object in the graph to represent this choice is a waste of cycles, so the load-balance object is always the result. If the route does not have ECMP, then the load-balance has only one choice.
- In order to collect per-route counters, the lookup result must in some way uniquely identify the *fib_entry_t*. A shared load-balance (contributed by the path-list) would not allow this.
- In the case the *fib_entry_t* has MPLS out labels, and hence a *fib_path_ext_t*, then the load-balance must be per-prefix, since the MPLS labels that are its parents are themselves per-fib_entry_t.
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
+- write custom DPOs/nodes for combined 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.
+ limited set of their use cases where performance is truly 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.
Code Review / vpp.git / blobdiff