diff options
Diffstat (limited to 'docs/gettingstarted/developers/fib20')
5 files changed, 15 insertions, 15 deletions
diff --git a/docs/gettingstarted/developers/fib20/dataplane.rst b/docs/gettingstarted/developers/fib20/dataplane.rst index 2a728c5a89a..a9e2bf27d69 100644 --- a/docs/gettingstarted/developers/fib20/dataplane.rst +++ b/docs/gettingstarted/developers/fib20/dataplane.rst @@ -68,7 +68,7 @@ stacking occurs, the necessary VLIB graph arcs are automatically constructed from the respected DPO type's registered graph nodes. The diagrams above show that for any given route the full data-plane graph is -known before anypacket arrives. If that graph is composed of n objects, then the +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 diff --git a/docs/gettingstarted/developers/fib20/graphwalks.rst b/docs/gettingstarted/developers/fib20/graphwalks.rst index e931c7ee70d..36fdb3f2723 100644 --- a/docs/gettingstarted/developers/fib20/graphwalks.rst +++ b/docs/gettingstarted/developers/fib20/graphwalks.rst @@ -15,8 +15,8 @@ child to parent relationship is thus fully known to the child, and hence a forwa walk of the graph (from child to parent) is trivial. However, a parent does not choose its children, it does not even choose the type. All object types that form part of the FIB control plane graph all inherit from a single base class14; *fib_node_t*. A *fib_node_t* -indentifies the object's index and its associated virtual function table provides the -parent a mechanism to Զisitՠthat object during the walk. The reason for a back-walk +identifies the object's index and its associated virtual function table provides the +parent a mechanism to visit that object during the walk. The reason for a back-walk is to inform all children that the state of the parent has changed in some way, and that the child may itself need to update. @@ -65,7 +65,7 @@ Choosing between a synchronous and an asynchronous walk is therefore a trade-off time it takes to propagate a change in the parent to all of its children, versus the time it takes to act on a single route update. For example, if a route update where to affect millions of child recursive routes, then the rate at which such updates could be -processed would be dependent on the number of child recursive route Рwhich would not be +processed would be dependent on the number of child recursive route which would not be good. At the time of writing FIB2.0 uses synchronous walk in all locations except when walking the children of a path-list, and it has more than 32 [#f15]_ children. This avoids the case mentioned above. diff --git a/docs/gettingstarted/developers/fib20/routes.rst b/docs/gettingstarted/developers/fib20/routes.rst index 62fcc00bd78..464a24af5d3 100644 --- a/docs/gettingstarted/developers/fib20/routes.rst +++ b/docs/gettingstarted/developers/fib20/routes.rst @@ -10,19 +10,19 @@ the route is resolved as the graph is complete from *fib_entry_t* to *ip_adjacen In some routing models a VRF will consist of a set of tables for IPv4 and IPv6, and unicast and multicast. In VPP there is no such grouping. Each table is distinct from -each other. A table is indentified by its numerical ID. The ID range is separate for +each other. A table is identified by its numerical ID. The ID range is separate for each address family. A table is comprised of two route data-bases; forwarding and non-forwarding. The forwarding data-base contains routes against which a packet will perform a longest prefix match (LPM) in the data-plane. The non-forwarding DB contains all the routes -with which VPP has been programmed Рsome of these routes may be unresolved for reasons +with which VPP has been programmed some of these routes may be unresolved for reasons that prevent their insertion into the forwarding DB (see section: Adjacency source FIB entries). The route data is decomposed into three parts; entry, path-list and paths; -* The *fib_entry_t*, which contains the routeճ prefix, is representation of that prefix's entry in the FIB table. +* The *fib_entry_t*, which contains the routes prefix, is representation of that prefix's entry in the FIB table. * The *fib_path_t* is a description of where to send the packets destined to the route's prefix. There are several types of path. * Attached next-hop: the path is described with an interface and a next-hop. The next-hop is in the same sub-net as the router's own address on that interface, hence the peer is considered to be *attached* @@ -37,10 +37,10 @@ The route data is decomposed into three parts; entry, path-list and paths; .. figure:: /_images/fib20fig2.png -Figure 2: Route data model Рclass diagram +Figure 2: Route data model class diagram Figure 2 shows an example of a route with two attached-next-hop paths. Each of these -paths will *resolve* by finding the adjacency that matches the pathճ attributes, which +paths will *resolve* by finding the adjacency that matches the paths attributes, which are the same as the key for the adjacency data-base [#f3]_. The *forwarding information (FI)* is the set of adjacencies that are available for load-balancing the traffic in the data-plane. A path *contributes* an adjacency to the route's forwarding information, the @@ -68,10 +68,10 @@ forwarding information of multiple sources to be combined. Instead the FIB must to use the forwarding information from only one source. This choice is based on a static priority assignment [#f4]_. The FIB must maintain the information each source has added so it can be restored should that source become the best source. VPP has two -*control-plane* sources; the API and the CLI Рthe API has the higher priority. +*control-plane* sources; the API and the CLI the API has the higher priority. Each *source* data is represented by a *fib_entry_src_t* object of which a *fib_entry_t* maintains a sorted vector.n A prefix is *connected* when it is -applied to a routerճ interface. +applied to a routers interface. The following configuration: @@ -84,7 +84,7 @@ attached, and 192.168.1.1/32 which is connected and local (a.k.a receive or for- Both prefixes are *interface* sourced. The interface source has a high priority, so the accidental or nefarious addition of identical prefixes does not prevent the router from correctly forwarding. Packets matching a connected prefix will -generate an ARP request for the packetճ destination address, this process is known +generate an ARP request for the packets destination address, this process is known as a *glean*. An *attached* prefix also results in a glean, but the router does not have its own @@ -147,7 +147,7 @@ So while the following configuration is accepted: $ ip arp 192.168.1.2 GigabitEthernet0/8/0 dead.dead.dead $ set interface ip table GigabitEthernet0/8/0 2 -it does not result in the desired behaviour, where the adj-fib and connecteds are +it does not result in the desired behaviour, where the adj-fib and connected adjacencies are moved to table 2. Recursive Routes diff --git a/docs/gettingstarted/developers/fib20/scale.rst b/docs/gettingstarted/developers/fib20/scale.rst index c97297d4adc..8cee1f1835c 100644 --- a/docs/gettingstarted/developers/fib20/scale.rst +++ b/docs/gettingstarted/developers/fib20/scale.rst @@ -93,7 +93,7 @@ IP6 Heap The IPv6 heap is used to allocate the memory needed for the data-structure within which the IPv6 prefixes are stored. IPv6 also has the concept of forwarding and non-forwarding entries, however for -IPv6 all the forwardind entries are stored in a single hash table +IPv6 all the forwarding entries are stored in a single hash table (same goes for the non-forwarding). The key to the hash table includes the IPv6 table-id. diff --git a/docs/gettingstarted/developers/fib20/tunnels.rst b/docs/gettingstarted/developers/fib20/tunnels.rst index 4c1dfe2a07d..1613a69df8c 100644 --- a/docs/gettingstarted/developers/fib20/tunnels.rst +++ b/docs/gettingstarted/developers/fib20/tunnels.rst @@ -23,7 +23,7 @@ graph/chain rather than its usual terminal location. The mid-chain adjacency is contributed by the gre_tunnel_t , which also becomes part of the FIB control-plane graph. Consequently it will be visited by a -back-walk when the forwarding information for the tunnelճ destination changes. +back-walk when the forwarding information for the tunnel's destination changes. This will trigger it to restack the mid-chain adjacency on the new *load_balance_t* contributed by the parent *fib_entry_t*. |