summaryrefslogtreecommitdiffstats
path: root/docs/gettingstarted/writingdocs/styleguide/styleguide05.rst
blob: 7ea977358c126d08af02abbd5be9f18034a46f03 (plain) 
1
2
3
4
5
6
7
8
9
10
11

.. _styleguide05:

********
Raw HTML
********

An html frame can be included with the following construct. It is recommended that references to raw html be included with it's own .rst file.

.. toctree::

  rawhtml.rst
'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.