diff options
Diffstat (limited to 'docs/overview/whatisvpp')
| -rw-r--r-- | docs/overview/whatisvpp/dataplane.rst | 36 | ||||
| -rw-r--r-- | docs/overview/whatisvpp/developer.rst | 26 | ||||
| -rw-r--r-- | docs/overview/whatisvpp/extensible.rst | 39 | ||||
| -rw-r--r-- | docs/overview/whatisvpp/fast.rst | 18 | ||||
| -rw-r--r-- | docs/overview/whatisvpp/index.rst | 27 | ||||
| -rw-r--r-- | docs/overview/whatisvpp/what-is-vector-packet-processing.rst | 73 |
6 files changed, 0 insertions, 219 deletions
diff --git a/docs/overview/whatisvpp/dataplane.rst b/docs/overview/whatisvpp/dataplane.rst deleted file mode 100644 index daf2124158d..00000000000 --- a/docs/overview/whatisvpp/dataplane.rst +++ /dev/null @@ -1,36 +0,0 @@ -.. _packet-processing: - -=================== -Packet Processing -=================== - -This section identifies different components of packet processing and describes their benefits: - -* Layer 2 - 4 Network Stack - - * Fast lookup tables for routes, bridge entries - * Arbitrary n-tuple classifiers - * Control Plane, Traffic Management and Overlays - -* `Linux <https://en.wikipedia.org/wiki/Linux>`_ and `FreeBSD <https://en.wikipedia.org/wiki/FreeBSD>`_ support - - * Wide support for standard Operating System Interfaces such as AF_Packet, Tun/Tap & Netmap. - -* Wide network and cryptographic hardware support with `DPDK <https://www.dpdk.org/>`_. -* Container and Virtualization support - - * Para-virtualized interfaces; Vhost and Virtio - * Network Adapters over PCI passthrough - * Native container interfaces; MemIF - -* Universal Data Plane: one code base, for many use cases - - * Discrete appliances; such as `Routers <https://en.wikipedia.org/wiki/Router_(computing)>`_ and `Switches <https://en.wikipedia.org/wiki/Network_switch>`_. - * `Cloud Infrastructure and Virtual Network Functions <https://en.wikipedia.org/wiki/Network_function_virtualization>`_ - * `Cloud Native Infrastructure <https://www.cncf.io/>`_ - * The same binary package for all use cases. - -* Out of the box production quality, with thanks to `CSIT <https://wiki.fd.io/view/CSIT#Start_Here>`_. - -For more information, please see :ref:`features` for the complete list. - diff --git a/docs/overview/whatisvpp/developer.rst b/docs/overview/whatisvpp/developer.rst deleted file mode 100644 index 040762b01ba..00000000000 --- a/docs/overview/whatisvpp/developer.rst +++ /dev/null @@ -1,26 +0,0 @@ -.. _developer-friendly: - -================== -Developer Friendly -================== - -This section describes the different ways VPP is friendly to developers: - -* Extensive runtime counters; throughput, `intructions per cycle <https://en.wikipedia.org/wiki/Instructions_per_cycle>`_, errors, events etc. -* Integrated pipeline tracing facilities -* Multi-language API bindings -* Integrated command line for debugging -* Fault-tolerant and upgradable - - * Runs as a standard user-space process for fault tolerance, software crashes seldom require more than a process restart. - * Improved fault-tolerance and upgradability when compared to running similar packet processing in the kernel, software updates never require system reboots. - * Development experience is easier compared to similar kernel code - * Hardware isolation and protection (`iommu <https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit>`_) - -* Built for security - - * Extensive white-box testing - * Image segment base address randomization - * Shared-memory segment base address randomization - * Stack bounds checking - * Static analysis with `Coverity <https://en.wikipedia.org/wiki/Coverity>`_ diff --git a/docs/overview/whatisvpp/extensible.rst b/docs/overview/whatisvpp/extensible.rst deleted file mode 100644 index e7762d71312..00000000000 --- a/docs/overview/whatisvpp/extensible.rst +++ /dev/null @@ -1,39 +0,0 @@ -.. _extensible: - -============================= -Extensible and Modular Design -============================= - -* Pluggable, easy to understand & extend -* Mature graph node architecture -* Full control to reorganize the pipeline -* Fast, plugins are equal citizens - -**Modular, Flexible, and Extensible** - -The FD.io VPP packet processing pipeline is decomposed into a ‘packet processing -graph’. This modular approach means that anyone can ‘plugin’ new graph -nodes. This makes VPP easily extensible and means that plugins can be -customized for specific purposes. VPP is also configurable through it's -Low-Level API. - -.. figure:: /_images/VPP_custom_application_packet_processing_graph.280.jpg - :alt: Extensible, modular graph node architecture? - - Extensible and modular graph node architecture. - -At runtime, the FD.io VPP platform assembles a vector of packets from RX rings, -typically up to 256 packets in a single vector. The packet processing graph is -then applied, node by node (including plugins) to the entire packet vector. The -received packets typically traverse the packet processing graph nodes in the -vector, when the network processing represented by each graph node is applied to -each packet in turn. Graph nodes are small and modular, and loosely -coupled. This makes it easy to introduce new graph nodes and rewire existing -graph nodes. - -Plugins are `shared libraries <https://en.wikipedia.org/wiki/Library_(computing)>`_ -and are loaded at runtime by VPP. VPP find plugins by searching the plugin path -for libraries, and then dynamically loads each one in turn on startup. -A plugin can introduce new graph nodes or rearrange the packet processing graph. -You can build a plugin completely independently of the FD.io VPP source tree, -which means you can treat it as an independent component. diff --git a/docs/overview/whatisvpp/fast.rst b/docs/overview/whatisvpp/fast.rst deleted file mode 100644 index 9e9e314809c..00000000000 --- a/docs/overview/whatisvpp/fast.rst +++ /dev/null @@ -1,18 +0,0 @@ -.. _fast: - -================================ -Fast, Scalable and Deterministic -================================ - -This section describes the ways that VPP is fast, scalable and deterministic: - -* `Continuous integration and system testing (CSIT) <https://wiki.fd.io/view/CSIT#Start_Here>`_ - - * Including continuous & extensive, latency and throughput testing - -* Layer 2 Cross Connect (L2XC), typically achieve 15+ Mpps per core. -* Tested to achieve **zero** packet drops and ~15µs latency. -* Performance scales linearly with core/thread count -* Supporting millions of concurrent lookup tables entries - -Please see :ref:`performance` for more information. diff --git a/docs/overview/whatisvpp/index.rst b/docs/overview/whatisvpp/index.rst deleted file mode 100644 index f8cb25dfd1e..00000000000 --- a/docs/overview/whatisvpp/index.rst +++ /dev/null @@ -1,27 +0,0 @@ -.. _whatisvpp: - -========================================= -What is VPP? -========================================= - -FD.io's Vector Packet Processing (VPP) technology is a :ref:`fast`, -:ref:`packet-processing` stack that runs on commodity CPUs. It provides -out-of-the-box production quality switch/router functionality and much, much -more. FD.io VPP is at the same time, an :ref:`extensible` and -:ref:`developer-friendly` framework, capable of boot-strapping the development -of packet-processing applications. The benefits of FD.io VPP are its high -performance, proven technology, its modularity and flexibility, integrations and -rich feature set. - -FD.io VPP is vector packet processing software, to learn more about what that -means, see the :ref:`what-is-vector-packet-processing` section. - -For more detailed information on FD.io features, see the following sections: - -.. toctree:: - :maxdepth: 1 - - dataplane.rst - fast.rst - developer.rst - extensible.rst diff --git a/docs/overview/whatisvpp/what-is-vector-packet-processing.rst b/docs/overview/whatisvpp/what-is-vector-packet-processing.rst deleted file mode 100644 index 50a5bab8af1..00000000000 --- a/docs/overview/whatisvpp/what-is-vector-packet-processing.rst +++ /dev/null @@ -1,73 +0,0 @@ -:orphan: - -.. _what-is-vector-packet-processing: - -================================= -What is vector packet processing? -================================= - -FD.io VPP is developed using vector packet processing concepts, as opposed to -scalar packet processing, these concepts are explained in the following sections. - -Vector packet processing is a common approach among high performance `Userspace -<https://en.wikipedia.org/wiki/User_space>`_ packet processing applications such -as developed with FD.io VPP and `DPDK -<https://en.wikipedia.org/wiki/Data_Plane_Development_Kit>`_. The scalar based -approach tends to be favoured by Operating System `Kernel -<https://en.wikipedia.org/wiki/Kernel_(operating_system)>`_ Network Stacks and -Userspace stacks that don't have strict performance requirements. - -**Scalar Packet Processing** - -A scalar packet processing network stack typically processes one packet at a -time: an interrupt handling function takes a single packet from a Network -Interface, and processes it through a set of functions: fooA calls fooB calls -fooC and so on. - -.. code-block:: none - - +---> fooA(packet1) +---> fooB(packet1) +---> fooC(packet1) - +---> fooA(packet2) +---> fooB(packet2) +---> fooC(packet2) - ... - +---> fooA(packet3) +---> fooB(packet3) +---> fooC(packet3) - - -Scalar packet processing is simple, but inefficient in these ways: - -* When the code path length exceeds the size of the Microprocessor's instruction - cache (I-cache), `thrashing - <https://en.wikipedia.org/wiki/Thrashing_(computer_science)>`_ occurs as the - Microprocessor is continually loading new instructions. In this model, each - packet incurs an identical set of I-cache misses. -* The associated deep call stack will also add load-store-unit pressure as - stack-locals fall out of the Microprocessor's Layer 1 Data Cache (D-cache). - -**Vector Packet Processing** - -In contrast, a vector packet processing network stack processes multiple packets -at a time, called 'vectors of packets' or simply a 'vector'. An interrupt -handling function takes the vector of packets from a Network Interface, and -processes the vector through a set of functions: fooA calls fooB calls fooC and -so on. - -.. code-block:: none - - +---> fooA([packet1, +---> fooB([packet1, +---> fooC([packet1, +---> - packet2, packet2, packet2, - ... ... ... - packet256]) packet256]) packet256]) - -This approach fixes: - -* The I-cache thrashing problem described above, by amortizing the cost of - I-cache loads across multiple packets. - -* The inefficiencies associated with the deep call stack by receiving vectors - of up to 256 packets at a time from the Network Interface, and processes them - using a directed graph of node. The graph scheduler invokes one node dispatch - function at a time, restricting stack depth to a few stack frames. - -The further optimizations that this approaches enables are pipelining and -prefetching to minimize read latency on table data and parallelize packet loads -needed to process packets. - |