docs/overview/whatisvpp/extensible.rst

   1 .. _extensible:
   2
   3 =============================
   4 Extensible and Modular Design
   5 =============================
   6
   7 * Pluggable, easy to understand & extend
   8 * Mature graph node architecture
   9 * Full control to reorganize the pipeline
  10 * Fast, plugins are equal citizens
  11
  12 **Modular, Flexible, and Extensible**
  13
  14 The FD.io VPP packet processing pipeline is decomposed into a ‘packet processing
  15 graph’.  This modular approach means that anyone can ‘plugin’ new graph
  16 nodes. This makes VPP easily extensible and means that plugins can be
  17 customized for specific purposes. VPP is also configurable through it's
  18 Low-Level API.
  19
  20 .. figure:: /_images/VPP_custom_application_packet_processing_graph.280.jpg
  21    :alt: Extensible, modular graph node architecture?
  22
  23    Extensible and modular graph node architecture.
  24
  25 At runtime, the FD.io VPP platform assembles a vector of packets from RX rings,
  26 typically up to 256 packets in a single vector. The packet processing graph is
  27 then applied, node by node (including plugins) to the entire packet vector. The
  28 received packets typically traverse the packet processing graph nodes in the
  29 vector, when the network processing represented by each graph node is applied to
  30 each packet in turn.  Graph nodes are small and modular, and loosely
  31 coupled. This makes it easy to introduce new graph nodes and rewire existing
  32 graph nodes.
  33
  34 Plugins are `shared libraries <https://en.wikipedia.org/wiki/Library_(computing)>`_
  35 and are loaded at runtime by VPP. VPP find plugins by searching the plugin path
  36 for libraries, and then dynamically loads each one in turn on startup.
  37 A plugin can introduce new graph nodes or rearrange the packet processing graph.
  38 You can build a plugin completely independently of the FD.io VPP source tree,
  39 which means you can treat it as an independent component.