diff options
51 files changed, 101 insertions, 102 deletions
diff --git a/docs/featuresbyrelease/vpp1908.md b/docs/featuresbyrelease/vpp1908.md index 6eb3453ff4f..32a6f5810b1 100644 --- a/docs/featuresbyrelease/vpp1908.md +++ b/docs/featuresbyrelease/vpp1908.md @@ -10,7 +10,7 @@ - 19.05 integration - Remove bonding code - Rework extended stats -- Debugging & Servicability +- Debugging & Serviceability - debug CLI leak-checker - vlib: add "memory-trace stats-segment" - vppapitrace JSON/API trace converter @@ -130,7 +130,7 @@ - support quic streams and "connectable listeners" - worker unregister api - fix epoll with large events batch - - ldp: add option to eanble transparent TLS connections + - ldp: add option to enable transparent TLS connections - udp: - support close with data - fixed session migration diff --git a/docs/gettingstarted/developers/bihash.md b/docs/gettingstarted/developers/bihash.md index a0d652f4f6c..bc4dc1b1b34 100644 --- a/docs/gettingstarted/developers/bihash.md +++ b/docs/gettingstarted/developers/bihash.md @@ -74,7 +74,7 @@ search across 2**log2_size backing pages on a per-bucket basis. To maintain *space* efficiency, we should configure the bucket array so that backing pages are effectively utilized. Lookup performance -tends to change *very litte* if the bucket array is too small or too +tends to change *very little* if the bucket array is too small or too large. Bihash depends on selecting an effective hash function. If one were to diff --git a/docs/gettingstarted/developers/binary_api_support.rst b/docs/gettingstarted/developers/binary_api_support.rst index 9c17a734e44..732ce978daa 100644 --- a/docs/gettingstarted/developers/binary_api_support.rst +++ b/docs/gettingstarted/developers/binary_api_support.rst @@ -93,7 +93,7 @@ implement a variety of features: * Barrier synchronization of worker threads across thread-unsafe message handlers. Correctly-coded message handlers know nothing about the transport used -to deliver messages to/from VPP. It's reasonably straighforward to use +to deliver messages to/from VPP. It's reasonably straightforward to use multiple API message transport types simultaneously. For historical reasons, binary api messages are (putatively) sent in diff --git a/docs/gettingstarted/developers/building.rst b/docs/gettingstarted/developers/building.rst index 3c6c3b96e8f..4d7af16bc18 100644 --- a/docs/gettingstarted/developers/building.rst +++ b/docs/gettingstarted/developers/building.rst @@ -164,7 +164,7 @@ Once the packages are built they can be found in the build-root directory. vpp-plugins_18.07-rc0~456-gb361076_amd64.deb Finally, the created packages can be installed using the following commands. Install -the package that correspnds to OS that VPP will be running on: +the package that corresponds to OS that VPP will be running on: For Ubuntu: diff --git a/docs/gettingstarted/developers/buildsystem/buildrootmakefile.rst b/docs/gettingstarted/developers/buildsystem/buildrootmakefile.rst index 089c15afefd..6963aecb9f3 100644 --- a/docs/gettingstarted/developers/buildsystem/buildrootmakefile.rst +++ b/docs/gettingstarted/developers/buildsystem/buildrootmakefile.rst @@ -156,7 +156,7 @@ Here are the contents of .../build-data/platforms/vpp.mk: vpp_uses_dpdk = yes - # Uncoment to enable building unit tests + # Uncomment to enable building unit tests # vpp_enable_tests = yes vpp_root_packages = vpp vom diff --git a/docs/gettingstarted/developers/fib20/dataplane.rst b/docs/gettingstarted/developers/fib20/dataplane.rst index 2a728c5a89a..a9e2bf27d69 100644 --- a/docs/gettingstarted/developers/fib20/dataplane.rst +++ b/docs/gettingstarted/developers/fib20/dataplane.rst @@ -68,7 +68,7 @@ stacking occurs, the necessary VLIB graph arcs are automatically constructed from the respected DPO type's registered graph nodes. The diagrams above show that for any given route the full data-plane graph is -known before anypacket arrives. If that graph is composed of n objects, then the +known before any packet arrives. If that graph is composed of n objects, then the packet will visit n nodes and thus incur a forwarding cost of approximately n times the graph node cost. This could be reduced if the graph were *collapsed* into a single DPO and associated node. However, collapsing a graph removes the diff --git a/docs/gettingstarted/developers/fib20/graphwalks.rst b/docs/gettingstarted/developers/fib20/graphwalks.rst index e931c7ee70d..36fdb3f2723 100644 --- a/docs/gettingstarted/developers/fib20/graphwalks.rst +++ b/docs/gettingstarted/developers/fib20/graphwalks.rst @@ -15,8 +15,8 @@ child to parent relationship is thus fully known to the child, and hence a forwa walk of the graph (from child to parent) is trivial. However, a parent does not choose its children, it does not even choose the type. All object types that form part of the FIB control plane graph all inherit from a single base class14; *fib_node_t*. A *fib_node_t* -indentifies the object's index and its associated virtual function table provides the -parent a mechanism to Զisitՠthat object during the walk. The reason for a back-walk +identifies the object's index and its associated virtual function table provides the +parent a mechanism to visit that object during the walk. The reason for a back-walk is to inform all children that the state of the parent has changed in some way, and that the child may itself need to update. @@ -65,7 +65,7 @@ Choosing between a synchronous and an asynchronous walk is therefore a trade-off time it takes to propagate a change in the parent to all of its children, versus the time it takes to act on a single route update. For example, if a route update where to affect millions of child recursive routes, then the rate at which such updates could be -processed would be dependent on the number of child recursive route Рwhich would not be +processed would be dependent on the number of child recursive route which would not be good. At the time of writing FIB2.0 uses synchronous walk in all locations except when walking the children of a path-list, and it has more than 32 [#f15]_ children. This avoids the case mentioned above. diff --git a/docs/gettingstarted/developers/fib20/routes.rst b/docs/gettingstarted/developers/fib20/routes.rst index 62fcc00bd78..464a24af5d3 100644 --- a/docs/gettingstarted/developers/fib20/routes.rst +++ b/docs/gettingstarted/developers/fib20/routes.rst @@ -10,19 +10,19 @@ the route is resolved as the graph is complete from *fib_entry_t* to *ip_adjacen In some routing models a VRF will consist of a set of tables for IPv4 and IPv6, and unicast and multicast. In VPP there is no such grouping. Each table is distinct from -each other. A table is indentified by its numerical ID. The ID range is separate for +each other. A table is identified by its numerical ID. The ID range is separate for each address family. A table is comprised of two route data-bases; forwarding and non-forwarding. The forwarding data-base contains routes against which a packet will perform a longest prefix match (LPM) in the data-plane. The non-forwarding DB contains all the routes -with which VPP has been programmed Рsome of these routes may be unresolved for reasons +with which VPP has been programmed some of these routes may be unresolved for reasons that prevent their insertion into the forwarding DB (see section: Adjacency source FIB entries). The route data is decomposed into three parts; entry, path-list and paths; -* The *fib_entry_t*, which contains the routeճ prefix, is representation of that prefix's entry in the FIB table. +* The *fib_entry_t*, which contains the routes prefix, is representation of that prefix's entry in the FIB table. * The *fib_path_t* is a description of where to send the packets destined to the route's prefix. There are several types of path. * Attached next-hop: the path is described with an interface and a next-hop. The next-hop is in the same sub-net as the router's own address on that interface, hence the peer is considered to be *attached* @@ -37,10 +37,10 @@ The route data is decomposed into three parts; entry, path-list and paths; .. figure:: /_images/fib20fig2.png -Figure 2: Route data model Рclass diagram +Figure 2: Route data model class diagram Figure 2 shows an example of a route with two attached-next-hop paths. Each of these -paths will *resolve* by finding the adjacency that matches the pathճ attributes, which +paths will *resolve* by finding the adjacency that matches the paths attributes, which are the same as the key for the adjacency data-base [#f3]_. The *forwarding information (FI)* is the set of adjacencies that are available for load-balancing the traffic in the data-plane. A path *contributes* an adjacency to the route's forwarding information, the @@ -68,10 +68,10 @@ forwarding information of multiple sources to be combined. Instead the FIB must to use the forwarding information from only one source. This choice is based on a static priority assignment [#f4]_. The FIB must maintain the information each source has added so it can be restored should that source become the best source. VPP has two -*control-plane* sources; the API and the CLI Рthe API has the higher priority. +*control-plane* sources; the API and the CLI the API has the higher priority. Each *source* data is represented by a *fib_entry_src_t* object of which a *fib_entry_t* maintains a sorted vector.n A prefix is *connected* when it is -applied to a routerճ interface. +applied to a routers interface. The following configuration: @@ -84,7 +84,7 @@ attached, and 192.168.1.1/32 which is connected and local (a.k.a receive or for- Both prefixes are *interface* sourced. The interface source has a high priority, so the accidental or nefarious addition of identical prefixes does not prevent the router from correctly forwarding. Packets matching a connected prefix will -generate an ARP request for the packetճ destination address, this process is known +generate an ARP request for the packets destination address, this process is known as a *glean*. An *attached* prefix also results in a glean, but the router does not have its own @@ -147,7 +147,7 @@ So while the following configuration is accepted: $ ip arp 192.168.1.2 GigabitEthernet0/8/0 dead.dead.dead $ set interface ip table GigabitEthernet0/8/0 2 -it does not result in the desired behaviour, where the adj-fib and connecteds are +it does not result in the desired behaviour, where the adj-fib and connected adjacencies are moved to table 2. Recursive Routes diff --git a/docs/gettingstarted/developers/fib20/scale.rst b/docs/gettingstarted/developers/fib20/scale.rst index c97297d4adc..8cee1f1835c 100644 --- a/docs/gettingstarted/developers/fib20/scale.rst +++ b/docs/gettingstarted/developers/fib20/scale.rst @@ -93,7 +93,7 @@ IP6 Heap The IPv6 heap is used to allocate the memory needed for the data-structure within which the IPv6 prefixes are stored. IPv6 also has the concept of forwarding and non-forwarding entries, however for -IPv6 all the forwardind entries are stored in a single hash table +IPv6 all the forwarding entries are stored in a single hash table (same goes for the non-forwarding). The key to the hash table includes the IPv6 table-id. diff --git a/docs/gettingstarted/developers/fib20/tunnels.rst b/docs/gettingstarted/developers/fib20/tunnels.rst index 4c1dfe2a07d..1613a69df8c 100644 --- a/docs/gettingstarted/developers/fib20/tunnels.rst +++ b/docs/gettingstarted/developers/fib20/tunnels.rst @@ -23,7 +23,7 @@ graph/chain rather than its usual terminal location. The mid-chain adjacency is contributed by the gre_tunnel_t , which also becomes part of the FIB control-plane graph. Consequently it will be visited by a -back-walk when the forwarding information for the tunnelճ destination changes. +back-walk when the forwarding information for the tunnel's destination changes. This will trigger it to restack the mid-chain adjacency on the new *load_balance_t* contributed by the parent *fib_entry_t*. diff --git a/docs/gettingstarted/developers/gdb_examples.rst b/docs/gettingstarted/developers/gdb_examples.rst index 71340dabcd0..893987796cf 100644 --- a/docs/gettingstarted/developers/gdb_examples.rst +++ b/docs/gettingstarted/developers/gdb_examples.rst @@ -32,7 +32,7 @@ or abort signal, then you can run the VPP debug binary and then execute **backtr (gdb) bt #0 ip4_icmp_input (vm=0x7ffff7b89a40 <vlib_global_main>, node=0x7fffb6bb6900, frame=0x7fffb6725ac0) at /scratch/vpp-master/build-data/../src/vnet/ip/icmp4.c:187 #1 0x00007ffff78da4be in dispatch_node (vm=0x7ffff7b89a40 <vlib_global_main>, node=0x7fffb6bb 6900, type=VLIB_NODE_TYPE_INTERNAL, dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7fffb6725ac0, last_time_stamp=10581236529 65565) at /scratch/vpp-master/build-data/../src/vlib/main.c:988 - #2 0x00007ffff78daa77 in dispatch_pending_node (vm=0x7ffff7b89a40 <vlib_global_main>, pending_f rame_index=6, last_time_stamp=1058123652965565) at /scratch/vpp-master/build-data/../src/vlib/main.c:1138 + #2 0x00007ffff78daa77 in dispatch_pending_node (vm=0x7ffff7b89a40 <vlib_global_main>, pending_frame_index=6, last_time_stamp=1058123652965565) at /scratch/vpp-master/build-data/../src/vlib/main.c:1138 .... Get to the GDB prompt diff --git a/docs/gettingstarted/developers/infrastructure.md b/docs/gettingstarted/developers/infrastructure.md index 95465f0a1e2..2c798f4a337 100644 --- a/docs/gettingstarted/developers/infrastructure.md +++ b/docs/gettingstarted/developers/infrastructure.md @@ -161,7 +161,7 @@ format specification. For example: format\_junk() can invoke other user-format functions if desired. The programmer shoulders responsibility for argument type-checking. It is -typical for user format functions to blow up spectaculary if the +typical for user format functions to blow up spectacularly if the va\_arg(va, type) macros don't match the caller's idea of reality. Unformat diff --git a/docs/gettingstarted/developers/metadata.md b/docs/gettingstarted/developers/metadata.md index 1f7f5c72bcf..2f20596c0d9 100644 --- a/docs/gettingstarted/developers/metadata.md +++ b/docs/gettingstarted/developers/metadata.md @@ -31,7 +31,7 @@ the pre-data (rewrite space) area. * VNET_BUFFER_F_L4_CHECKSUM_COMPUTED: tcp/udp checksum has been computed * VNET_BUFFER_F_L4_CHECKSUM_CORRECT: tcp/udp checksum is correct * VNET_BUFFER_F_VLAN_2_DEEP: two vlan tags present - * VNET_BUFFER_F_VLAN_1_DEEP: one vlag tag present + * VNET_BUFFER_F_VLAN_1_DEEP: one vlan tag present * VNET_BUFFER_F_SPAN_CLONE: packet has already been cloned (span feature) * VNET_BUFFER_F_LOOP_COUNTER_VALID: packet look-up loop count valid * VNET_BUFFER_F_LOCALLY_ORIGINATED: packet built by vpp @@ -48,13 +48,13 @@ the pre-data (rewrite space) area. * VNET_BUFFER_F_IS_DVR: packet to be reinjected into the l2 output path * VNET_BUFFER_F_QOS_DATA_VALID: QoS data valid in vnet_buffer_opaque2 * VNET_BUFFER_F_GSO: generic segmentation offload requested - * VNET_BUFFER_F_AVAIL1: avaliable bit - * VNET_BUFFER_F_AVAIL2: avaliable bit - * VNET_BUFFER_F_AVAIL3: avaliable bit - * VNET_BUFFER_F_AVAIL4: avaliable bit - * VNET_BUFFER_F_AVAIL5: avaliable bit - * VNET_BUFFER_F_AVAIL6: avaliable bit - * VNET_BUFFER_F_AVAIL7: avaliable bit + * VNET_BUFFER_F_AVAIL1: available bit + * VNET_BUFFER_F_AVAIL2: available bit + * VNET_BUFFER_F_AVAIL3: available bit + * VNET_BUFFER_F_AVAIL4: available bit + * VNET_BUFFER_F_AVAIL5: available bit + * VNET_BUFFER_F_AVAIL6: available bit + * VNET_BUFFER_F_AVAIL7: available bit * u32 flow_id: generic flow identifier * u8 ref_count: buffer reference / clone count (e.g. for span replication) * u8 buffer_pool_index: buffer pool index which owns this buffer diff --git a/docs/gettingstarted/developers/multiarch/index.rst b/docs/gettingstarted/developers/multiarch/index.rst index a1dfe98bd62..824a8e68438 100644 --- a/docs/gettingstarted/developers/multiarch/index.rst +++ b/docs/gettingstarted/developers/multiarch/index.rst @@ -3,7 +3,7 @@ Multi-architecture support ========================== -This reference guide describes how to use the vpp muli-architecture support scheme +This reference guide describes how to use the vpp multi-architecture support scheme .. toctree:: :maxdepth: 1 diff --git a/docs/gettingstarted/developers/vnet.md b/docs/gettingstarted/developers/vnet.md index 89169efb8d4..f9d7bd597fa 100644 --- a/docs/gettingstarted/developers/vnet.md +++ b/docs/gettingstarted/developers/vnet.md @@ -325,7 +325,7 @@ these data to easily filter/track single packets as they traverse the forwarding graph. Multiple records per packet are normal, and to be expected. Packets -will appear multipe times as they traverse the vpp forwarding +will appear multiple times as they traverse the vpp forwarding graph. In this way, vpp graph dispatch traces are significantly different from regular network packet captures from an end-station. This property complicates stateful packet analysis. @@ -494,7 +494,7 @@ These commands have the following optional parameters: capture is off. - <b>max-bytes-per-pkt _nnnn_</b> - maximum number of bytes to trace - on a per-paket basis. Must be >32 and less than 9000. Default value: + on a per-packet basis. Must be >32 and less than 9000. Default value: 512. - <b>filter</b> - Use the pcap rx / tx / drop trace filter, which must @@ -529,7 +529,7 @@ These commands have the following optional parameters: The "classify filter pcap | <interface-name> " debug CLI command constructs an arbitrary set of packet classifier tables for use with "pcap rx | tx | drop trace," and with the vpp packet tracer on a -per-interrface basis. +per-interface basis. Packets which match a rule in the classifier table chain will be traced. The tables are automatically ordered so that matches in the @@ -538,7 +538,7 @@ most specific table are tried first. It's reasonably likely that folks will configure a single table with one or two matches. As a result, we configure 8 hash buckets and 128K of match rule space by default. One can override the defaults by -specifiying "buckets <nnn>" and "memory-size <xxx>" as desired. +specifying "buckets <nnn>" and "memory-size <xxx>" as desired. To build up complex filter chains, repeatedly issue the classify filter debug CLI command. Each command must specify the desired mask diff --git a/docs/gettingstarted/developers/vpp_api_module.rst b/docs/gettingstarted/developers/vpp_api_module.rst index 261c8691dc2..3cdea524e4e 100644 --- a/docs/gettingstarted/developers/vpp_api_module.rst +++ b/docs/gettingstarted/developers/vpp_api_module.rst @@ -56,7 +56,7 @@ _______ **Low-level API** -Refer to inline API documentation in doxygen format in vapi.h header for description of functions. It's recommened to use the safer, high-level API provided by specialized headers (e.g. vpe.api.vapi.h or vpe.api.vapi.hpp). +Refer to inline API documentation in doxygen format in vapi.h header for description of functions. It's recommended to use the safer, high-level API provided by specialized headers (e.g. vpe.api.vapi.h or vpe.api.vapi.hpp). **C high-level API** @@ -113,7 +113,7 @@ _________ *Create a Connection and execute the appropriate Request to subscribe to events (e.g. Want_stats)* -#. Create an Event_registration with a template argument being the type of event you are insterested in. +#. Create an Event_registration with a template argument being the type of event you are interested in. #. Call dispatch() or wait_for_response() to wait for the event. A callback will be called when an event occurs (if passed to Event_registration() constructor). Alternatively, read the result set. .. note:: diff --git a/docs/gettingstarted/progressivevpp/index.rst b/docs/gettingstarted/progressivevpp/index.rst index 458beda57bc..ab257f25258 100644 --- a/docs/gettingstarted/progressivevpp/index.rst +++ b/docs/gettingstarted/progressivevpp/index.rst @@ -7,7 +7,7 @@ Progressive VPP Tutorial ######################## Learn to run FD.io VPP on a single Ubuntu 16.04 VM using Vagrant with this walkthrough -covering basic FD.io VPP senarios. Useful FD.io VPP commands will be used, and +covering basic FD.io VPP scenarios. Useful FD.io VPP commands will be used, and will discuss basic operations, and the state of a running FD.io VPP on a system. .. note:: diff --git a/docs/gettingstarted/progressivevpp/switching.rst b/docs/gettingstarted/progressivevpp/switching.rst index 72005080b08..a28e860fdaa 100644 --- a/docs/gettingstarted/progressivevpp/switching.rst +++ b/docs/gettingstarted/progressivevpp/switching.rst @@ -9,7 +9,7 @@ Skills to be Learned ---------------------- #. Associate an interface with a bridge domain -#. Create a loopback interaface +#. Create a loopback interface #. Create a BVI (Bridge Virtual Interface) for a bridge domain #. Examine a bridge domain @@ -46,7 +46,7 @@ To clear existing config from previous exercises run: $ ps -ef | grep vpp | awk '{print $2}'| xargs sudo kill $ sudo ip link del dev vpp1host - $ # do the next command if you are cleaing up from this example + $ # do the next command if you are cleaning up from this example $ sudo ip link del dev vpp1vpp2 Run FD.io VPP instances diff --git a/docs/gettingstarted/progressivevpp/twovppinstances.rst b/docs/gettingstarted/progressivevpp/twovppinstances.rst index 7a8bbe0fd1c..7ac9b5e87ba 100644 --- a/docs/gettingstarted/progressivevpp/twovppinstances.rst +++ b/docs/gettingstarted/progressivevpp/twovppinstances.rst @@ -83,7 +83,7 @@ socket **/run/vpp/cli-vpp1.sock** vpp# create interface memif id 0 master This will create an interface on vpp1 memif0/0 using /run/vpp/memif as -its socket file. The role of vpp1 for this memif inteface is 'master'. +its socket file. The role of vpp1 for this memif interface is 'master'. With what you have learned: @@ -104,7 +104,7 @@ run/vpp/memif-vpp1vpp2 socket file vpp# create interface memif id 0 slave This will create an interface on vpp2 memif0/0 using /run/vpp/memif as -its socket file. The role of vpp1 for this memif inteface is 'slave'. +its socket file. The role of vpp1 for this memif interface is 'slave'. Use your previously used skills to: diff --git a/docs/gettingstarted/users/configuring/hugepages.rst b/docs/gettingstarted/users/configuring/hugepages.rst index 3019a203c79..7a1e0bd8057 100644 --- a/docs/gettingstarted/users/configuring/hugepages.rst +++ b/docs/gettingstarted/users/configuring/hugepages.rst @@ -24,7 +24,7 @@ the hugepage settings, perform the following commands: # All groups allowed to access hugepages vm.hugetlb_shm_group=0 - # Shared Memory Max must be greator or equal to the total size of hugepages. + # Shared Memory Max must be greater or equal to the total size of hugepages. # For 2MB pages, TotalHugepageSize = vm.nr_hugepages * 2 * 1024 * 1024 # If the existing kernel.shmmax setting (cat /sys/proc/kernel/shmmax) # is greater than the calculated TotalHugepageSize then set this parameter diff --git a/docs/gettingstarted/users/configuring/startup.rst b/docs/gettingstarted/users/configuring/startup.rst index df96ff7ae2e..7a663944261 100644 --- a/docs/gettingstarted/users/configuring/startup.rst +++ b/docs/gettingstarted/users/configuring/startup.rst @@ -244,7 +244,7 @@ attributes. **Example:** cli-prompt vpp-2 * **cli-history-limit <n>** - Limit commmand history to <n> lines. A value of 0 disables command history. + Limit command history to <n> lines. A value of 0 disables command history. Default value: 50 **Example:** cli-history-limit 100 @@ -336,7 +336,7 @@ Popular options include: for all NICs except VICs, using ENIC driver, which has VLAN stripping on by default. * **hqos** - Enable the Hierarchical Quaity-of-Service (HQoS) scheduler, default is + Enable the Hierarchical Quality-of-Service (HQoS) scheduler, default is disabled. This enables HQoS on specific output interface. * **hqos { .. }** HQoS can also have its own set of custom parameters. Setting a custom @@ -413,7 +413,7 @@ Popular options include: **Example:** enable-tcp-udp-checksum * **no-multi-seg** - Disable mutli-segment buffers, improves performance but disables Jumbo MTU + Disable multi-segment buffers, improves performance but disables Jumbo MTU support. **Example:** no-multi-seg @@ -435,7 +435,7 @@ Popular options include: **Example:** log-level error * **dev default { .. }** - Change default settings for all intefaces. This sections supports the + Change default settings for all interfaces. This sections supports the same set of custom parameters described in *'dev <pci-dev> { .. }*'. **Example:** @@ -1216,8 +1216,8 @@ ____________________ A plugin can be disabled by default. It may still be in an experimental phase or only be needed in special circumstances. If this is the case, the plugin can -be explicitely enabled in *'startup.conf'*. Also, a plugin that is enabled by -default can be explicitely disabled in *'startup.conf'*. +be explicitly enabled in *'startup.conf'*. Also, a plugin that is enabled by +default can be explicitly disabled in *'startup.conf'*. Another useful use of this section is to disable all the plugins, then enable only the plugins that are desired. diff --git a/docs/gettingstarted/users/configutil/sysinfo.rst b/docs/gettingstarted/users/configutil/sysinfo.rst index 893f94999ce..77dd1c778c2 100644 --- a/docs/gettingstarted/users/configutil/sysinfo.rst +++ b/docs/gettingstarted/users/configutil/sysinfo.rst @@ -11,15 +11,15 @@ Threads ------- It usually is not needed, but VPP can be configured to run on isolated CPUs. In the example shown -VPP is configured with 2 workers. The main thread is also configured to run on a seperate CPU. The -stats thread will always run on CPU 0. This utilty will put the worker threads on CPUs that are +VPP is configured with 2 workers. The main thread is also configured to run on a separate CPU. The +stats thread will always run on CPU 0. This utility will put the worker threads on CPUs that are associated with the ports that are configured. Grub Command Line ----------------- In general the Grub command line does not need to be changed. If the system is running many processes -it may be neccessary to isolate CPUs for VPP or other processes. +it may be necessary to isolate CPUs for VPP or other processes. Huge Pages ---------- diff --git a/docs/gettingstarted/writingdocs/styleguide/index.rst b/docs/gettingstarted/writingdocs/styleguide/index.rst index 443476f83b6..240b3a26b19 100644 --- a/docs/gettingstarted/writingdocs/styleguide/index.rst +++ b/docs/gettingstarted/writingdocs/styleguide/index.rst @@ -10,7 +10,7 @@ the Sphinx Markup Constructs used in these documents. The Sphinx style guide can For a more detailed list of Sphinx Markup Constructs please refer to: `Sphinx Markup Constructs <http://www.sphinx-doc.org/en/stable/markup/index.html>`_ -This document is also an example of a directory structure for a document that spans mutliple pages. +This document is also an example of a directory structure for a document that spans multiple pages. Notice we have the file **index.rst** and the then documents that are referenced in index.rst. The referenced documents are shown at the bottom of this page. diff --git a/docs/gettingstarted/writingdocs/styleguide/styleguide02.rst b/docs/gettingstarted/writingdocs/styleguide/styleguide02.rst index e2d7649f585..af92c93c316 100644 --- a/docs/gettingstarted/writingdocs/styleguide/styleguide02.rst +++ b/docs/gettingstarted/writingdocs/styleguide/styleguide02.rst @@ -16,7 +16,7 @@ Bold text can be show with **Bold Text**, Italics with *Italic text*. Bullets li Notes ***** -A note can be used to describe something not in the normal flow of the paragragh. This +A note can be used to describe something not in the normal flow of the paragraph. This is an example of a note. .. note:: @@ -28,7 +28,7 @@ is an example of a note. Code Blocks *********** -This paragraph describes how to do **Console Commands**. When showing VPP commands it is reccomended +This paragraph describes how to do **Console Commands**. When showing VPP commands it is recommended that the command be executed from the linux console as shown. The Highlighting in the final documents shows up nicely this way. diff --git a/docs/gettingstarted/writingdocs/styleguide/styleguide04.rst b/docs/gettingstarted/writingdocs/styleguide/styleguide04.rst index 1bc4210de78..7dcea37d9d3 100644 --- a/docs/gettingstarted/writingdocs/styleguide/styleguide04.rst +++ b/docs/gettingstarted/writingdocs/styleguide/styleguide04.rst @@ -4,7 +4,7 @@ Including a file **************** -A complete file should be included with the following construct. It is recomended it be included with +A complete file should be included with the following construct. It is recommended it be included with it's own .rst file describing the file included. This is an example of an xml file is included. .. toctree:: diff --git a/docs/gettingstarted/writingdocs/styleguidemd/styleguide02.md b/docs/gettingstarted/writingdocs/styleguidemd/styleguide02.md index b297d328082..5582d7224c9 100644 --- a/docs/gettingstarted/writingdocs/styleguidemd/styleguide02.md +++ b/docs/gettingstarted/writingdocs/styleguidemd/styleguide02.md @@ -11,7 +11,7 @@ Code Blocks =========== This paragraph describes how to do **Console Commands**. When showing -VPP commands it is reccomended that the command be executed from the +VPP commands it is recommended that the command be executed from the linux console as shown. The Highlighting in the final documents shows up nicely this way. diff --git a/docs/overview/features/l2.rst b/docs/overview/features/l2.rst index 56c12053ab8..939afb7e8be 100644 --- a/docs/overview/features/l2.rst +++ b/docs/overview/features/l2.rst @@ -12,7 +12,7 @@ MAC Layer Discovery --------- -* Cisco Discovery Protocol +* Cisco Discovery Protocol v2 (CDP) * Link Layer Discovery Protocol (LLDP) Link Layer Control Protocol diff --git a/docs/overview/performance/index.rst b/docs/overview/performance/index.rst index 1c250206fcf..25e3897ff37 100644 --- a/docs/overview/performance/index.rst +++ b/docs/overview/performance/index.rst @@ -27,7 +27,7 @@ These features have been designed to take full advantage of common micro-process * Reducing cache and TLS misses by processing packets in vectors * Realizing `IPC <https://en.wikipedia.org/wiki/Instructions_per_cycle>`_ gains with vector instructions such as: SSE, AVX and NEON * Eliminating mode switching, context switches and blocking, to always be doing useful work -* Cache-lined aliged buffers for cache and memory efficiency +* Cache-lined aligned buffers for cache and memory efficiency Packet Throughput Graphs diff --git a/docs/overview/whatisvpp/dataplane.rst b/docs/overview/whatisvpp/dataplane.rst index 256165f4f8c..daf2124158d 100644 --- a/docs/overview/whatisvpp/dataplane.rst +++ b/docs/overview/whatisvpp/dataplane.rst @@ -16,10 +16,10 @@ This section identifies different components of packet processing and describes * Wide support for standard Operating System Interfaces such as AF_Packet, Tun/Tap & Netmap. -* Wide network and cryptograhic hardware support with `DPDK <https://www.dpdk.org/>`_. +* Wide network and cryptographic hardware support with `DPDK <https://www.dpdk.org/>`_. * Container and Virtualization support - * Para-virtualized intefaces; Vhost and Virtio + * Para-virtualized interfaces; Vhost and Virtio * Network Adapters over PCI passthrough * Native container interfaces; MemIF diff --git a/docs/overview/whatisvpp/developer.rst b/docs/overview/whatisvpp/developer.rst index 57000d45880..040762b01ba 100644 --- a/docs/overview/whatisvpp/developer.rst +++ b/docs/overview/whatisvpp/developer.rst @@ -14,7 +14,7 @@ This section describes the different ways VPP is friendly to developers: * Runs as a standard user-space process for fault tolerance, software crashes seldom require more than a process restart. * Improved fault-tolerance and upgradability when compared to running similar packet processing in the kernel, software updates never require system reboots. - * Development expierence is easier compared to similar kernel code + * Development experience is easier compared to similar kernel code * Hardware isolation and protection (`iommu <https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit>`_) * Built for security diff --git a/docs/overview/whatisvpp/extensible.rst b/docs/overview/whatisvpp/extensible.rst index c271dad7d14..e7762d71312 100644 --- a/docs/overview/whatisvpp/extensible.rst +++ b/docs/overview/whatisvpp/extensible.rst @@ -13,7 +13,7 @@ Extensible and Modular Design The FD.io VPP packet processing pipeline is decomposed into a ‘packet processing graph’. This modular approach means that anyone can ‘plugin’ new graph -nodes. This makes VPP easily exensible and means that plugins can be +nodes. This makes VPP easily extensible and means that plugins can be customized for specific purposes. VPP is also configurable through it's Low-Level API. diff --git a/docs/overview/whatisvpp/what-is-vector-packet-processing.rst b/docs/overview/whatisvpp/what-is-vector-packet-processing.rst index 994318e81c5..50a5bab8af1 100644 --- a/docs/overview/whatisvpp/what-is-vector-packet-processing.rst +++ b/docs/overview/whatisvpp/what-is-vector-packet-processing.rst @@ -13,7 +13,7 @@ Vector packet processing is a common approach among high performance `Userspace <https://en.wikipedia.org/wiki/User_space>`_ packet processing applications such as developed with FD.io VPP and `DPDK <https://en.wikipedia.org/wiki/Data_Plane_Development_Kit>`_. The scalar based -aproach tends to be favoured by Operating System `Kernel +approach tends to be favoured by Operating System `Kernel <https://en.wikipedia.org/wiki/Kernel_(operating_system)>`_ Network Stacks and Userspace stacks that don't have strict performance requirements. @@ -21,7 +21,7 @@ Userspace stacks that don't have strict performance requirements. A scalar packet processing network stack typically processes one packet at a time: an interrupt handling function takes a single packet from a Network -Inteface, and processes it through a set of functions: fooA calls fooB calls +Interface, and processes it through a set of functions: fooA calls fooB calls fooC and so on. .. code-block:: none @@ -32,7 +32,7 @@ fooC and so on. +---> fooA(packet3) +---> fooB(packet3) +---> fooC(packet3) -Scalar packet processing is simple, but inefficent in these ways: +Scalar packet processing is simple, but inefficient in these ways: * When the code path length exceeds the size of the Microprocessor's instruction cache (I-cache), `thrashing @@ -46,7 +46,7 @@ Scalar packet processing is simple, but inefficent in these ways: In contrast, a vector packet processing network stack processes multiple packets at a time, called 'vectors of packets' or simply a 'vector'. An interrupt -handling function takes the vector of packets from a Network Inteface, and +handling function takes the vector of packets from a Network Interface, and processes the vector through a set of functions: fooA calls fooB calls fooC and so on. @@ -59,10 +59,10 @@ so on. This approach fixes: -* The I-cache thrashing problem described above, by ammoritizing the cost of +* The I-cache thrashing problem described above, by amortizing the cost of I-cache loads across multiple packets. -* The ineffeciences associated with the deep call stack by recieving vectors +* The inefficiencies associated with the deep call stack by receiving vectors of up to 256 packets at a time from the Network Interface, and processes them using a directed graph of node. The graph scheduler invokes one node dispatch function at a time, restricting stack depth to a few stack frames. diff --git a/docs/reference/cmdreference/index.rst b/docs/reference/cmdreference/index.rst index c51dd367ae0..c791992f779 100644 --- a/docs/reference/cmdreference/index.rst +++ b/docs/reference/cmdreference/index.rst @@ -27,7 +27,7 @@ The debug CLI can be executed from a su (superuser) shell using the vppctl comma drops 1498 local0 0 down -Commands can also be executed from the vppct shell. +Commands can also be executed from the vppctl shell. .. code-block:: console diff --git a/docs/reference/cmdreference/interface/create_interface.rst b/docs/reference/cmdreference/interface/create_interface.rst index c646a9947ad..9aeae33e98b 100644 --- a/docs/reference/cmdreference/interface/create_interface.rst +++ b/docs/reference/cmdreference/interface/create_interface.rst @@ -133,14 +133,13 @@ This command has several variations: - **create sub-interfaces** <*interface*> <*subId*>-<*subId*> - Create a range of subinterfaces to handle a range of VLAN IDs. - **create sub-interfaces** <*interface*> <*subId*> dot1q|dot1ad <*vlanId*>|any - [exact-match] - Use this command to specify the outer VLAN ID, to - either be explicited or to make the VLAN ID different from the - *subId*. + [exact-match] - Use this command to explicitly specify the outer VLAN ID, + or to make the VLAN ID different from the *subId*. - **create sub-interfaces** <*interface*> <*subId*> dot1q|dot1ad <*vlanId*>|any inner-dot1q <*vlanId*>|any [exact-match] - Use this command to - specify the outer VLAN ID and the innner VLAN ID. + specify the outer VLAN ID and the inner VLAN ID. -When *dot1q* or *dot1ad* is explictly entered, subinterfaces can be +When *dot1q* or *dot1ad* is explicitly entered, subinterfaces can be configured as either *exact-match* or *non-exact match*. *Non-exact match* is the CLI default. If *exact-match* is specified, packets must have the same number of VLAN tags as the configuration. For *non-exact-match*, diff --git a/docs/reference/cmdreference/show/show.rst b/docs/reference/cmdreference/show/show.rst index ba4938edac6..61c53604594 100644 --- a/docs/reference/cmdreference/show/show.rst +++ b/docs/reference/cmdreference/show/show.rst @@ -64,7 +64,7 @@ This command displays the IPv4 FIB Tables (VRF Tables) and the route entries for .. note::
This command will run for a long time when the FIB tables are comprised of
- millions of entries. For those senarios, consider displaying a single table or summary mode.
+ millions of entries. For those scenarios, consider displaying a single table or summary mode.
Example Usage
--------------
diff --git a/docs/reference/cmdreference/vhost/vhostuser.rst b/docs/reference/cmdreference/vhost/vhostuser.rst index 04669bc5dea..0c2498b7f2c 100644 --- a/docs/reference/cmdreference/vhost/vhostuser.rst +++ b/docs/reference/cmdreference/vhost/vhostuser.rst @@ -28,7 +28,7 @@ There are several parameters associated with a vHost interface: Interface. In '*client*' mode, VPP can be reset without bringing down the VM and tearing down the vHost Interface. - **feature-mask <hex>** - Optional virtio/vhost feature set negotiated - at startup. **This is intended for degugging only.** It is + at startup. **This is intended for debugging only.** It is recommended that this parameter not be used except by experienced users. By default, all supported features will be advertised. Otherwise, provide the set of features desired. @@ -91,7 +91,7 @@ Show Vhost-User Display the attributes of a single vHost User interface (provide interface name), multiple vHost User interfaces (provide a list of -interface names seperated by spaces) or all Vhost User interfaces (omit +interface names separated by spaces) or all Vhost User interfaces (omit an interface name to display all vHost interfaces). Summary/Usage diff --git a/docs/reference/vppvagrant/Vagrantfile b/docs/reference/vppvagrant/Vagrantfile index 32a13adedd8..457e37c8274 100644 --- a/docs/reference/vppvagrant/Vagrantfile +++ b/docs/reference/vppvagrant/Vagrantfile @@ -60,7 +60,7 @@ Vagrant.configure(2) do |config| config.vm.network "private_network", type: "dhcp" end - # use http proxy if avaiable + # use http proxy if available if ENV['http_proxy'] && Vagrant.has_plugin?("vagrant-proxyconf") config.proxy.http = ENV['http_proxy'] config.proxy.https = ENV['https_proxy'] @@ -112,4 +112,4 @@ Vagrant.configure(2) do |config| vws.vmx["memsize"] = "#{vmram}" vws.vmx["numvcpus"] = "#{vmcpu}" end -end
\ No newline at end of file +end diff --git a/docs/reference/vppvagrant/boxSetup.rst b/docs/reference/vppvagrant/boxSetup.rst index 374ba349458..a8aa1f3c132 100644 --- a/docs/reference/vppvagrant/boxSetup.rst +++ b/docs/reference/vppvagrant/boxSetup.rst @@ -62,7 +62,7 @@ Looking further in the :ref:`vppVagrantfile`, you can see more Ruby variables be config.vm.network "private_network", type: "dhcp" end - # use http proxy if avaiable + # use http proxy if available if ENV['http_proxy'] && Vagrant.has_plugin?("vagrant-proxyconf") config.proxy.http = ENV['http_proxy'] config.proxy.https = ENV['https_proxy'] @@ -122,4 +122,4 @@ To confirm it is up, show the status and information of Vagrant boxes with: $ vagrant destroy <id> - Note that "destroying" a VM does not erase the box, but rather destroys all resources allocated for that VM. For other Vagrant commands, such as destroying a box, refer to the `Vagrant CLI Page <https://www.vagrantup.com/docs/cli/>`_.
\ No newline at end of file + Note that "destroying" a VM does not erase the box, but rather destroys all resources allocated for that VM. For other Vagrant commands, such as destroying a box, refer to the `Vagrant CLI Page <https://www.vagrantup.com/docs/cli/>`_. diff --git a/docs/usecases/ConnectingVPC.rst b/docs/usecases/ConnectingVPC.rst index 8ecb790def0..cc8c927b2cb 100644 --- a/docs/usecases/ConnectingVPC.rst +++ b/docs/usecases/ConnectingVPC.rst @@ -5,7 +5,7 @@ Interconnecting VPCs with Segment Routing & Performance Evaluation ____________________________________________________________________ -Before reading this part, you should have a minimum understading of AWS, especially on `VPC concepts <https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html>`_. +Before reading this part, you should have a minimum understanding of AWS, especially on `VPC concepts <https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html>`_. @@ -22,7 +22,7 @@ In our VPC we will have two instances: one, in which we will install VPP and the .. figure:: /_images/vpc_scheme.svg -Figure 2: Example of the resourses present inside our VPC +Figure 2: Example of the resources present inside our VPC Notice that the following example works with two VPCs, where in each of them there are a VM with VPP and a VM. Hence, you will have to execute the same commands also in the other VPC to make the connection between the two VPC possibile. diff --git a/docs/usecases/Routing.rst b/docs/usecases/Routing.rst index 0c5908fd57e..31929d31603 100644 --- a/docs/usecases/Routing.rst +++ b/docs/usecases/Routing.rst @@ -75,7 +75,7 @@ We see that the IP has been assigned, as well as our default gateway. Now exit this container and repeat this process with container *ctwo*, except with IP 172.16.2.2/24 and gateway 172.16.2.1. -After thats done for *both* containers, exit from the container if you're in one: +After that's done for *both* containers, exit from the container if you're in one: .. code-block:: console @@ -261,6 +261,6 @@ At long last you probably want to see some pings: rtt min/avg/max/mdev = 0.089/0.098/0.111/0.014 ms -Which should send/recieve three packets for each command. +Which should send/receive three packets for each command. -This is the end of this guide. Great work!
\ No newline at end of file +This is the end of this guide. Great work! diff --git a/docs/usecases/acls.rst b/docs/usecases/acls.rst index 36023571779..0350af2d969 100644 --- a/docs/usecases/acls.rst +++ b/docs/usecases/acls.rst @@ -482,7 +482,7 @@ Match an IPv6…. Links ~~~~~ -- `Overview of classifers <https://wiki.fd.io/view/VPP/SecurityGroups#Existing_functionality>`__ +- `Overview of classifiers <https://wiki.fd.io/view/VPP/SecurityGroups#Existing_functionality>`__ - `FD.io VPP Classifiers Overview <https://wiki.fd.io/view/VPP/Introduction_To_N-tuple_Classifiers>`__ - `FD.io VPP Classifiers CLI <https://docs.fd.io/vpp/19.04/clicmd_src_vnet_classify.html>`__ - `Sample Code from Andrew Yourt <http://stdio.be/vpp/t/aytest-bridge-tap-py.txt>`__ diff --git a/docs/usecases/automatingthedeployment.rst b/docs/usecases/automatingthedeployment.rst index 6772b18e4e5..25317e2d0a0 100644 --- a/docs/usecases/automatingthedeployment.rst +++ b/docs/usecases/automatingthedeployment.rst @@ -7,6 +7,6 @@ __________________________ -In order to make the VPP deployment easier inside AWS and Azure, we have created two different Terraform scripts, compatibles with both Public Cloud Provider. These scripts allow to automate the deployment of the resources. `Here you can find the scripts anf further informations <https://github.com/francescospinelli94/Automating-Deployment-VPP>`_. +In order to make the VPP deployment easier inside AWS and Azure, we have created two different Terraform scripts, compatibles with both Public Cloud Provider. These scripts allow to automate the deployment of the resources. `Here you can find the scripts anf further information <https://github.com/francescospinelli94/Automating-Deployment-VPP>`_. diff --git a/docs/usecases/contiv/BUG_REPORTS.md b/docs/usecases/contiv/BUG_REPORTS.md index 648e67f2422..5b9c3cf4875 100644 --- a/docs/usecases/contiv/BUG_REPORTS.md +++ b/docs/usecases/contiv/BUG_REPORTS.md @@ -283,7 +283,7 @@ Prerequisites: access to sudo. #### Setting up Prerequisites -To enable looging into a node without a password, copy your public key to the following +To enable logging into a node without a password, copy your public key to the following node: ``` ssh-copy-id <user-id>@<node-name-or-ip-address> diff --git a/docs/usecases/contiv/K8s_Overview.md b/docs/usecases/contiv/K8s_Overview.md index e3d8e1a0d44..ba3a8e12524 100644 --- a/docs/usecases/contiv/K8s_Overview.md +++ b/docs/usecases/contiv/K8s_Overview.md @@ -3,7 +3,7 @@ ## Overview -Kubernates is a container orchestration system that efficiently manages Docker containers. The Docker containers and container platforms provide many advantages over traditional virtualization. Container isolation is done on the kernel level, which eliminates the need for a guest virtual operating system, and therefore makes containers much more efficient, faster, and lightweight. The containers in Contiv/VPP are referred to as PODs. +Kubernetes is a container orchestration system that efficiently manages Docker containers. The Docker containers and container platforms provide many advantages over traditional virtualization. Container isolation is done on the kernel level, which eliminates the need for a guest virtual operating system, and therefore makes containers much more efficient, faster, and lightweight. The containers in Contiv/VPP are referred to as PODs. Contiv/VPP is a Kubernetes network plugin that uses [FD.io VPP](https://fd.io/) to provide network connectivity between PODs in a k8s cluster (k8s is an abbreviated reference for kubernates). diff --git a/docs/usecases/contiv/MANUAL_INSTALL.md b/docs/usecases/contiv/MANUAL_INSTALL.md index d91a83a610c..35506db0d16 100644 --- a/docs/usecases/contiv/MANUAL_INSTALL.md +++ b/docs/usecases/contiv/MANUAL_INSTALL.md @@ -1,9 +1,9 @@ # Manual Installation -This document describes how to clone the Contiv respository and then use [kubeadm][1] to manually install Kubernetes +This document describes how to clone the Contiv repository and then use [kubeadm][1] to manually install Kubernetes with Contiv-VPP networking on one or more bare metal or VM hosts. -## Clone the Contiv Respository -To clone the Contiv respository enter the following command: +## Clone the Contiv Repository +To clone the Contiv repository enter the following command: ``` git clone https://github.com/contiv/vpp/<repository-name> ``` diff --git a/docs/usecases/contiv/MULTI_NIC_SETUP.md b/docs/usecases/contiv/MULTI_NIC_SETUP.md index 5cbb031d290..cacbcbb464b 100644 --- a/docs/usecases/contiv/MULTI_NIC_SETUP.md +++ b/docs/usecases/contiv/MULTI_NIC_SETUP.md @@ -5,7 +5,7 @@ described [here](https://github.com/contiv/vpp/blob/master/docs/VPP_CONFIG.md#mu * For each interface owned by Linux, you need to provide individual configuration for each interface used by VPP in the Node Configuration - for thenode in the `contiv-vpp.yaml`. For example, if both `ens3` and + for the node in the `contiv-vpp.yaml`. For example, if both `ens3` and `ens4` are known to Linux, then put the following stanza into the node's NodeConfig: ``` diff --git a/docs/usecases/contiv/VPP_PACKET_TRACING_K8S.md b/docs/usecases/contiv/VPP_PACKET_TRACING_K8S.md index f7b6f4c19e8..740918197e2 100644 --- a/docs/usecases/contiv/VPP_PACKET_TRACING_K8S.md +++ b/docs/usecases/contiv/VPP_PACKET_TRACING_K8S.md @@ -113,7 +113,7 @@ wildcard-ip4-arp-publisher-pro event wait 0 0 `tapcli-rx` above is the node-level input queue for incoming packets into all the pods on the node. There is one `tapcli-rx` input queue for every node. -The following are the input and output queueus for each pod and the node: +The following are the input and output queues for each pod and the node: ``` tapcli-0-output diff --git a/docs/usecases/simpleperf/iperf3.rst b/docs/usecases/simpleperf/iperf3.rst index 1d159d0eef2..0b0de373bff 100644 --- a/docs/usecases/simpleperf/iperf3.rst +++ b/docs/usecases/simpleperf/iperf3.rst @@ -3,7 +3,7 @@ Introduction ============ -This tutorial shows how to use VPP use iperf3 and Trex to get some basic peformance +This tutorial shows how to use VPP use iperf3 and Trex to get some basic performance numbers from a few basic configurations. Four examples are shown. In the first two examples, the **iperf3** tool is used to generate traffic, and in the last two examples the Cisco's `TRex Realistic Traffic Generator <http://trex-tgn.cisco.com/>`_ is used. For diff --git a/docs/usecases/simpleperf/trex2.rst b/docs/usecases/simpleperf/trex2.rst index adb1d10c736..590bfd05629 100644 --- a/docs/usecases/simpleperf/trex2.rst +++ b/docs/usecases/simpleperf/trex2.rst @@ -56,7 +56,7 @@ In the other terminal start the TRex console. With this console we will execute # cd v2.46/ # ./trex -console - Using 'python' as Python interpeter + Using 'python' as Python interpreter Connecting to RPC server on localhost:4501 [SUCCESS] @@ -152,7 +152,7 @@ More statistics can be displayed on the TRex console using the **tui** command. trex>tui - Global Statistitcs + Global Statistics connection : localhost, Port 4501 total_tx_L2 : 2.45 Gb/sec version : STL @ v2.46 total_tx_L1 : 2.59 Gb/sec diff --git a/docs/usecases/vmxnet3.rst b/docs/usecases/vmxnet3.rst index f3ec8d4b6f6..37fdbc82b67 100644 --- a/docs/usecases/vmxnet3.rst +++ b/docs/usecases/vmxnet3.rst @@ -58,7 +58,7 @@ If you are concerned more with configuration not performance the vmxnet3 driver can be set to **interrupt** mode in VPP. This will save a great deal on battery usage. Do this with the following -VMware Workstatiom PRO 15 for Linux +VMware Workstation PRO 15 for Linux ----------------------------------- VMware Workstation does not have a menu option to change the default driver diff --git a/docs/usecases/vppinazure.rst b/docs/usecases/vppinazure.rst index b2839a124a3..f64e2a7e7d1 100644 --- a/docs/usecases/vppinazure.rst +++ b/docs/usecases/vppinazure.rst @@ -61,7 +61,7 @@ And we reboot the instance: .. code-block:: console - $ reboot istance + $ reboot instance After the reboot, we type these commands: |