9ad39c026c
This patch refactors the VPP sphinx docs in order to make it easier to consume for external readers as well as VPP developers. It also makes sphinx the single source of documentation, which simplifies maintenance and operation. Most important updates are: - reformat the existing documentation as rst - split RELEASE.md and move it into separate rst files - remove section 'events' - remove section 'archive' - remove section 'related projects' - remove section 'feature by release' - remove section 'Various links' - make (Configuration reference, CLI docs, developer docs) top level items in the list - move 'Use Cases' as part of 'About VPP' - move 'Troubleshooting' as part of 'Getting Started' - move test framework docs into 'Developer Documentation' - add a 'Contributing' section for gerrit, docs and other contributer related infos - deprecate doxygen and test-docs targets - redirect the "make doxygen" target to "make docs" Type: refactor Change-Id: I552a5645d5b7964d547f99b1336e2ac24e7c209f Signed-off-by: Nathan Skrzypczak <nathan.skrzypczak@gmail.com> Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
48 lines
2.1 KiB
ReStructuredText
48 lines
2.1 KiB
ReStructuredText
Software Architecture
|
||
=====================
|
||
|
||
The fd.io vpp implementation is a third-generation vector packet
|
||
processing implementation specifically related to US Patent 7,961,636,
|
||
as well as earlier work. Note that the Apache-2 license specifically
|
||
grants non-exclusive patent licenses; we mention this patent as a point
|
||
of historical interest.
|
||
|
||
For performance, the vpp dataplane consists of a directed graph of
|
||
forwarding nodes which process multiple packets per invocation. This
|
||
schema enables a variety of micro-processor optimizations: pipelining
|
||
and prefetching to cover dependent read latency, inherent I-cache phase
|
||
behavior, vector instructions. Aside from hardware input and hardware
|
||
output nodes, the entire forwarding graph is portable code.
|
||
|
||
Depending on the scenario at hand, we often spin up multiple worker
|
||
threads which process ingress-hashes packets from multiple queues using
|
||
identical forwarding graph replicas.
|
||
|
||
VPP Layers - Implementation Taxonomy
|
||
------------------------------------
|
||
|
||
.. figure:: /_images/VPP_Layering.png
|
||
:alt: image
|
||
|
||
image
|
||
|
||
- VPP Infra - the VPP infrastructure layer, which contains the core
|
||
library source code. This layer performs memory functions, works with
|
||
vectors and rings, performs key lookups in hash tables, and works
|
||
with timers for dispatching graph nodes.
|
||
- VLIB - the vector processing library. The vlib layer also handles
|
||
various application management functions: buffer, memory and graph
|
||
node management, maintaining and exporting counters, thread
|
||
management, packet tracing. Vlib implements the debug CLI (command
|
||
line interface).
|
||
- VNET - works with VPP's networking interface (layers 2, 3, and 4)
|
||
performs session and traffic management, and works with devices and
|
||
the data control plane.
|
||
- Plugins - Contains an increasingly rich set of data-plane plugins, as
|
||
noted in the above diagram.
|
||
- VPP - the container application linked against all of the above.
|
||
|
||
It’s important to understand each of these layers in a certain amount of
|
||
detail. Much of the implementation is best dealt with at the API level
|
||
and otherwise left alone.
|