doc-dev: creating a dev doc.

doc-dev/BRICK_CONCEPT.md

@@ -0,0 +1,51 @@
+# Packetgraph's brick concept.
+
+## Overview.
+
+Each brick have 2 sides: East and West (except for monopole brick that have only one).<br>
+Each side can have 0 or more edges (except for dipole brick that have one edge per side).<br>
+Edges are stored in brick's sides and pointing to another brick.<br>
+So to create a link we need 2 edges... One from the first one pointing to the second one and vice versa.<br>
+Note: the side notion is for the packet's source, because it goes directly to a brick.<br>
+<br>
+A basic dipole brick shema:<br>
+```
+               |             |
+  edge  0  <---| +---------+ |--->edge  0
+  edge ... <---|-|  BRICK  |-|--->edge ...
+  edge  n  <---| +---------+ |--->edge  n
+               |             |
+               |             |
+               |             |
+               |             |
+           WEST SIDE     EAST SIDE
+```
+And now 2 basic bricks linked together:<br>
+```
+                      +-----B-West to A----+   +---A-East to B-------+
+                      |                    |   |                     |
+               |      V      |             |   |              |      V      | 
+  edge  0  <---| +---------+ |--->edge 0-------+  edge  0 <---| +---------+ |--->edge  0
+  edge ... <---|-| BRICK A |-|--->edge ... |      edge ...<---|-| BRICK B |-|--->edge ...
+  edge  n  <---| +---------+ |--->edge n   +------edge  n <---| +---------+ |--->edge  n
+               |             |                                |             |
+               |             |                                |             |
+               |             |                                |             |
+               |             |                                |             |
+           WEST SIDE     EAST SIDE                        WEST SIDE     EAST SIDE
+```
+<br>
+Why having sides?<br>
+Because it makes it easier to perform operations between two sides such as acting as a diode, filter...<br>
+
+## Brick's common operations.
+
+Packets are going through bricks via bursts. Bursts are started only from Inputs/Outputs of the graph (IO bricks: VHOST, NIC, RXTX, VTEP) during a graph poll. so polling bricks that are not IO bricks is a nonsense.<br>
+
+* `int burst(struct pg_brick *brick, enum pg_side from,uint16_t edge_index, struct rte_mbuf **pkts,uint64_t pkts_mask, struct       pg_error **errp);`<br>
+  Called to burst packets through an edge through a side to another brick though her other side.<br>
+  Example: If I burst from brick A through East side and edge 1 (pointing to brick B),<br>  brick B will receive it though West side.<br>
+* `int poll(struct pg_brick *brick, uint16_t *count, struct pg_error **errp);`<br>
+  Called during a graph poll.
+
+

doc-dev/README.md

@@ -0,0 +1,12 @@
+# DOC-DEV
+
+Here is a documentation aiming at providing detailed information about Packetgraph's brick concept, about implemented technology/features (with standards descriptions) and about each brick. The idea is to explain what's the purpose of each component, further optimizations and choices made.<br>
+<br>
+Detailed brick linking information and shema are availables here:
+* [Packetgraph's brick concept.](BRICK_CONCEPT.md)
+
+For specific brick'informations and shemas:
+* [VHOST brick.](VHOST.md)
+* [RXTX brick.](RXTX.md)
+* [VTEP brick.](VTEP.md)
+

doc-dev/RXTX.md

@@ -0,0 +1,21 @@
+# RXTX Brick
+
+## Introduction
+
+he RXTX brick is a monopole single-edge brick.<br>
+It is intended mainly for testing and benchmarking purpose.<br>
+We use it to create packet and send them through a graph and/or receive them.<br>
+
+## Usage
+
+Here is the constructor:
+```
+struct pg_brick *pg_rxtx_new(const char *name,
+                             pg_rxtx_rx_callback_t rx,
+                             pg_rxtx_tx_callback_t tx,
+                             void *private_data)
+```
+As we can see, we give it two callbacks as parameters:
+
+* `pg_rxtx_rx_callback_t rx`: The method that will be used to send packets.
+* `pg_rxtx_rx_callback_t tx`: The method that will be called whene the brick receive packets.

doc-dev/VHOST.md

@@ -0,0 +1,17 @@
++--------------------+
+|                    |
+|                    |
+|   Graph's side     |    Host's side
+|                |   |
+|   edge  1  <---| +--------+              +-------------+             +---------------+
+|   edge ... <---|-| VHOST  |<------------>| UNIX SOCKET |<----------->|Virtual-Machine|
+|   edge  n  <---| +--------+              +-------------+             +---------------+
+|                |   |  ^                                                       ^
+|               Side |  |                                                       |
+|                    |  |                                                       |
++--------------------+  v                                                       v
++--------------------------------------------------------------------------------------+
+|                                                                                      |
+|               Host's shared memmory, aka hugepage, containing packets.               |
+|                                                                                      |
++--------------------------------------------------------------------------------------+

doc-dev/VTEP.md

@@ -0,0 +1,42 @@
+  # VTEP Brick
+
+  ## Introduction
+
+  The VTEP brick is intended to allow us to use the VXLAN protocol.<br>
+  The VXLAN protocol is allowing us to create tunnels between multpiple LAN through another network.<br>
+
+  ## VXLAN protocol
+
+  THe VXLAN (Virtual Extensible LAN) protocol work by encapsulating packets before sending them through another network.<br>
+  It's all in the 2 OSI layer.
+
+  ## Usage
+
+  Our typical use case is making tunnels between virtual networks (or packetgraph's graphs) through the host's network via a NIC brick.<br>
+  When creating the brick, we tell her which side is the output (the tunnel's network), either East or West.<br>
+  This brick has an empty poll function because the only way to make packets going through ot is by bursting from an input/output of the graph.<br>
+
+  Example use case: making a tunnel between virtual networks 1 and 2 through the host's network.<br>
+  (NIC brick are described in the [NIC section](NIC.md))<br>
+  For a better link description between bricks, see [packetgraph's brick concept.](BRICK_CONCEPT.md)<br>
+  ```
+                           Virtual Network 1          |   Host's network   |           Virtual Network 2
+                                                      |                    |
+                                                      |                    |
+                            |            |            |                    |            |            |
+    Virtual Network  1  <---| +--------+ |       +---------+          +---------+       | +--------+ |---> Virtual Network  1
+    Virtual Network ... <---|-|  VTEP  |-|------>|   NIC   |----------|   NIC   |<------|-|  VTEP  |-|---> Virtual Network ...
+    Virtual Network  n  <---| +--------+ |       +---------+          +---------+       | +--------+ |---> Virtual Network  n
+                            |            |            |                    |            |            |
+                        West Side    East Side        |                    |        West Side    East Side
+                                                      |                    |
+                                                      |                    |
+
+
+  ```
+  Using the previous shema, it will be like if VN1 and VN2 were the same network.<br>
+
+  # Output redirection
+  The VTEP brick features her own switch. It is based on the VNI of each packet (Virtual Network Identifier).<br>
+  One vtep can lead to multiple virtual networks, each one identified by its own VNI.<br>
+  On a virtual network, there could be any kind of packetgraph brick, and why not another VTEP? If we want to encapsulate one more time the encapsulated network...<br>