ligang/vpp
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: Update sphinx, requirements, support markdown tables

Browse Source 
Change-Id: Ie7c546f5720b10fe5423397204e1ab5c22d7a2ba
Signed-off-by: jdenisco <jdenisco@cisco.com>
This commit is contained in:
jdenisco
2019-05-13 12:40:21 -04:00
committed by Dave Barach
parent 8fa01c17aa
commit 8a6e1b190c
9 changed files with 50 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/usecases/contiv/BUG_REPORTS.md
View File

@ -151,7 +151,7 @@ index 3676047..ffa4473 100644
valueFrom:
```
If VPP is the crashing process, please follow the [CORE_FILES](CORE_FILES.html) guide and provide the coredump file.
If VPP is the crashing process, please follow the \[CORE_FILES\](CORE_FILES.html) guide and provide the coredump file.
### Inspect VPP Config

6
docs/usecases/contiv/K8s_Overview.md
View File

@ -78,7 +78,7 @@ network stack, and data-plane NIC interface controlled by VPP:
- data-plane NIC is controlled directly by VPP using DPDK. Note, this means that
this interface is not visible to the host Linux network stack, and the node either needs another
management interface for k8s control plane communication, or
[STN (Steal The NIC)](SINGLE_NIC_SETUP.html) deployment must be applied.
\[STN (Steal The NIC)\](SINGLE_NIC_SETUP.html) deployment must be applied.
**Contiv VPP Agent** is the control plane part of the vSwitch container. It is responsible
for configuring the VPP according to the information gained from ETCD, and requests
@ -99,11 +99,11 @@ and replies with a response, which is then forwarded back to Kubelet.
### Contiv STN Daemon
This section discusses how the Contiv [STN (Steal The NIC)](SINGLE_NIC_SETUP.html) daemon operation works. As already mentioned, the default setup of Contiv/VPP requires two network interfaces
This section discusses how the Contiv \[STN (Steal The NIC)\](SINGLE_NIC_SETUP.html) daemon operation works. As already mentioned, the default setup of Contiv/VPP requires two network interfaces
per node: one controlled by VPP for data facing PODs, and one controlled by the host
network stack for k8s control plane communication. In case that your k8s nodes
do not provide two network interfaces, Contiv/VPP can work in the single NIC setup,
when the interface will be "stolen" from the host network stack just before starting
the VPP and configured with the same IP address on VPP, as well as
on the host-VPP interconnect TAP interface, as it had in the host before it.
For more information on STN setup, read the [Single NIC Setup README](./SINGLE_NIC_SETUP.html)
For more information on STN setup, read the \[Single NIC Setup README\](./SINGLE_NIC_SETUP.html)

4
docs/usecases/contiv/NETWORKING.md
View File

@ -20,7 +20,7 @@ ID is released back to the pool and will be re-used by the next node.
The Node ID is used to calculate per-node IP subnets for PODs
and other internal subnets that need to be unique on each node. Apart from the Node ID,
the input for IPAM calculations is a set of config knobs, which can be specified
in the `IPAMConfig` section of the [Contiv/VPP deployment YAML](../../../k8s/contiv-vpp.yaml):
in the `IPAMConfig` section of the \[Contiv/VPP deployment YAML\](../../../k8s/contiv-vpp.yaml):
- **PodSubnetCIDR** (default `10.1.0.0/16`): each pod gets an IP address assigned
from this range. The size of this range (default `/16`) dictates upper limit of
@ -132,6 +132,6 @@ whenever a node is added/deleted in the k8s cluster.
#### More Info
Please refer to the [Packet Flow Dev Guide](../dev-guide/PACKET_FLOW.html) for more
Please refer to the \[Packet Flow Dev Guide\](../dev-guide/PACKET_FLOW.html) for more
detailed description of paths traversed by request and response packets
inside Contiv/VPP Kubernetes cluster under different situations.

6
docs/usecases/contiv/SINGLE_NIC_SETUP.md
View File

@ -52,7 +52,7 @@ or individually for every node in the cluster.
Global configuration is used in homogeneous environments where all nodes in
a given cluster have the same hardware configuration, for example only a single
Network Adapter. To enable the STN feature globally, put the `StealFirstNIC: True`
stanza into the [`contiv-vpp.yaml`][1] deployment file, for example:
stanza into the \[`contiv-vpp.yaml`\]\[1\] deployment file, for example:
```
data:
contiv.yaml: |-
@ -67,13 +67,13 @@ Setting `StealFirstNIC` to `True` will tell the STN Daemon on every node in the
cluster to steal the first NIC from the kernel and assign it to VPP. Note that
the Network Adapters on different nodes do not need to be of the same type. You
still need to create the respective vswitch configurations on every node in the
cluster, as shown [above](#creating-a-vpp-interface-configuration).
cluster, as shown \[above\](#creating-a-vpp-interface-configuration).
##### Individual Configuration:
Individual configuration is used in heterogeneous environments where each node
in a given cluster may be configured differently. To enable the STN feature
for a specific node in the cluster, put the following stanza into its Node
Configuration in the [`contiv-vpp.yaml`][1] deployment file, for example:
Configuration in the \[`contiv-vpp.yaml`\]\[1\] deployment file, for example:
```
...
NodeConfig:

2
docs/usecases/contiv/VPPTRACE.md
View File

@ -1,7 +1,7 @@
## Using vpptrace.sh for VPP Packet Tracing
VPP allows tracing of incoming packets using CLI commands `trace add` and `show trace`
as explained [here](VPP_PACKET_TRACING_K8S.html), but it is a rather cumbersome process.
as explained \[here\](VPP_PACKET_TRACING_K8S.html), but it is a rather cumbersome process.
The buffer for captured packets is limited in size, and once it gets full the tracing stops. The user has to manually clear the buffer content, and then repeat the trace command to resume the packet capture, losing information about all packets received in the meantime.