VPP/DPOs and Feature Arcs
DPOs and Feature Arcs
Both DPOs and Feature arcs are both higher layer abstractions to construct the VLIB node graph.
DPOs are an abstract concept, a base class if you like, for objects that represent the actions that should be performed on the packet as it is switched. As you know, an object is both data and functions. Concrete DPO examples are adjacencies, load-balances, MPLS-labels etc, the object’s data then is the rewrite, ECMP choices and label value, respectively. The object’s function is the associated VLIB node. When DPOs are joined (or stacked in the FIB parlance) together into a list/graph or processing pipe-line, the infra code will ensure that the correct ‘underlay’ VLIB graph is constructed. A pipe-line thus consists of multiple VLIB nodes.
The use of the DPO concept is relatively new, so it not used by all VPP features, but there is no reason why it could not be. However, when considering whether to use this concept, bear in mind the object based pipe-line that can be constructed. Consider where it begins and where it ends – at present it begins as a result of an L3 destination lookup and terminates at a L2 rewrite (with an adjacency). This is possible because the L3 destination pre-determines all of those actions.
Features (like IPSEC and ACLs) are configured to run on (or are bound to) a particular interface. Each feature has a pre-determined order in which it will be run w.r.t. to other features on that interface. A Feature arc defines the resultant ordered set/graph of VLIB nodes that represent the ordered execution of those features. When progressing from feature A to feature B, we are not often able to make an association between a given object in that feature A with another in feature B – say IPSEC security association K, with ACL entry J – so constructing an object based pipe-line between features has no merit. Conversely we can say that FIB entry K is associated with adjacency J.
If we take ACLs as an example for possible DPO usage, the question to ask is what pipe-line can we build out of the actions the ACL performs, and, what other pipe-lines can we join it to. The starting point for an ACL (as an input or output feature) is a lookup or match operation; there’s nothing pre-determined there, and so no pipe-line it can be attached to. However, the subsequent actions post match could be modeled as a pipe-line of DPOs, particularly if the result is a set of forwarding actions – like policy based routing.
