docs: better docs, mv doxygen to sphinx
[vpp.git] / docs / aboutvpp / extensible.rst
similarity index 89%
rename from docs/whatisvpp/extensible.rst
rename to docs/aboutvpp/extensible.rst
index 1df3b9f..adba873 100644 (file)
@@ -4,7 +4,7 @@
 The Packet Processing Graph
 ===========================
 
-At the core of the FD.io VPP design is the **Packet Procerssing Graph**
+At the core of the FD.io VPP design is the **Packet Processing Graph**
 
 This makes the software:
 
@@ -21,8 +21,8 @@ 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. 
+
+   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
@@ -33,10 +33,10 @@ 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. 
+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.