fix some typo under doc/

fix typo change htttp_eflow4 to http_eflow4

Author: digger-yu

doc/analyticsBlog.asciidoc

@@ -25,7 +25,7 @@ endif::backend-xhtml11[]
 
 = How do we track TRex performance Using ElasticSearch, Grafana and Pandas
 The ability to monitor TRex performance on many setups/configurations on a daily basis may have a large impact on our ability to identify TRex performance degradation.  
-For a long time our monitoring method was based on hard coded boundaries, we have defined maximum and minimum values for each test/'s result and any exeception triggered a notification.
+For a long time our monitoring method was based on hard coded boundaries, we have defined maximum and minimum values for each test/'s result and any exception triggered a notification.
 This monitoring method had a lot of false positives which in turn increased the investigation time. Moreover this method introduced more complexity through the need to maintain the golden results for many test cases on various platforms.
 
 A new method was required which would enable us to:
@@ -104,7 +104,7 @@ image:images/blog/figure5.jpg[title="figure5",align="left",width={p_width}, link
 [small]#Figure 5# +
 
 https://github.com/cisco-system-traffic-generator/trex-core/blob/master/doc/AnalyticsConnect.py/[View this on GitHub] +
-More on: https://developers.google.com/analytics/devguides/reporting/core/v3/quickstart/service-py/[Google API on Documantation] [4]
+More on: https://developers.google.com/analytics/devguides/reporting/core/v3/quickstart/service-py/[Google API on Documentation] [4]
 
 ==	Analysis using python pandas
 ===	A word on Pandas

doc/packet_builder_yaml.asciidoc

@@ -113,7 +113,7 @@ The format should be *YAML*
 | uint64            |  sub fields of this header                       |  64
 | other class type  | name of other class. for example, "c-mac-addr"; take fields from there, optionally overload them later  | The size taken from that class
 | Payload           |     xref:Payload[Payload]                        | total packet size - all header until now
-| vlen_t            | in case of varible size header this include the size to the end of varible size header see example xref:IpvOption[Ipv4Option] |total size of the object
+| vlen_t            | in case of variable size header this include the size to the end of variable size header see example xref:IpvOption[Ipv4Option] |total size of the object
 |=================
 
 
@@ -189,7 +189,7 @@ The format should be *YAML*
 | next_headers       | string or type  |   a name of class that define the next or just an array                           |  "none"       | xref:Next_headers[Next_headers]  |
 | fields             | array           | array of Field_Type                                                               |   []          |        | fields : [  ]
 | offset             | integer/string  |   offset into the packet in bits, in case of auto add base of prev fields         |   "auto"      |        |
-| option             | string          |   a java code that define a way to calculate varible size                         |   "none"      |        |  |
+| option             | string          |   a java code that define a way to calculate variable size                         |   "none"      |        |  |
 |=================
 
 
@@ -318,7 +318,7 @@ root -> L2 (  Ethernet   , 802.3 , LLC SNAP  )
 * There would be a spare field in the Stream object so GUI could add more metadata for reconstructing the builder types
   for example in this example Ethernet/IP/TCP/IP/TCP  you can't extrac from buffer alone that Payload is IP/TCP only the builder known that in build time.
 * Ip total length need to keep the total_pkt_size - this ip header . this should work for internal header too.
-* When GUI add header ("external") the total size of this header should be calculated ( varible size should be given a default - ipv4)
+* When GUI add header ("external") the total size of this header should be calculated ( variable size should be given a default - ipv4)
 
 
 === Examples
@@ -385,7 +385,7 @@ other : Byte : Length ( +first) |option
 
 ----
 
-* case of varible length field ip_option example
+* case of variable length field ip_option example
 
 
 
@@ -401,7 +401,7 @@ other : Byte : Length ( +first) |option
    default : [0x00, 0x00, 0x01, 0x00, 0x00, 0x00]
    gui_representation:
       data_type  : "mac-addr_t" # format ([0-9a-fA-F]{2}:){5}[0-9a-fA-F]{2}
-      help  : "Mac addrees"
+      help  : "Mac address"
 
 
  - class : "ethernet"
@@ -560,7 +560,7 @@ other : Byte : Length ( +first) |option
 -  class : "root" # reserve
    gui_representation:
        help  : "Root"
-   next_headers : [ "ethrenet" ,"llc","_802-3"]
+   next_headers : [ "ethernet" ,"llc","_802-3"]
 ---------------------------
 
 
@@ -575,7 +575,7 @@ In this example parent class default value overrides default values of sub-field
    type : "uint8"
    array_size : 6
    gui_representation:
-      help  : "Mac addrees"
+      help  : "Mac address"
       data_type  : "mac-addr_t" # format ([0-9a-fA-F]{2}:){5}[0-9a-fA-F]{2}
    default : [0x00,0x00,0x01,0x00,0x00,0x00]
 

doc/release_notes_old.asciidoc

@@ -663,7 +663,7 @@ which was released on v2.16
 == Release 2.13 ==
 
 * Significantly improve performance and scale for stateful case with high active flows (70%-300% better)  see here link:trex_manual.html#_more_active_flows[More active flows]
-* Stateful with low active repeatable flows - an optimization was removed, for example `cap2/imix_fast_1g.yaml`. users that want to get this in high performance are adviced to move to Stateles mode. Removing this support improved the common case.
+* Stateful with low active repeatable flows - an optimization was removed, for example `cap2/imix_fast_1g.yaml`. users that want to get this in high performance are adviced to move to Stateless mode. Removing this support improved the common case.
 * Support NAT without IPv4.option and UDP flows- for ASA  link:https://trex-tgn.cisco.com/youtrack/issue/trex-274[trex-274]
 * Scapy server is restart automatically - for future Stateless GUI link:https://trex-tgn.cisco.com/youtrack/issue/trex-291[trex-291]
 * Add minimum ipg for remote pcap link:https://trex-tgn.cisco.com/youtrack/issue/trex-281[trex-281]
@@ -691,7 +691,7 @@ which was released on v2.16
 
 * Improve support for Mellanox ConnectX-4 cards (100/50/25GbE) 
 ** Only CentOs/RedHat 7.2 and up is supported due to OFED issues
-** Improve 64Byte Stateleess performance 
+** Improve 64Byte Stateless performance 
 * Cisco VIC is fully supported 
 * Stateless L2/L3 configuration mode for ports - link:trex_stateless.html#_port_layer_mode_configuration[Port Layer Mode Configuration]
 * Stateless neighboring protocols infra and first protocols support/Python API - link:trex_stateless.html#_neighboring_protocols[Neighboring Protocols]
@@ -799,7 +799,7 @@ See link:trex_manual.html#_configuration_yaml_parameter_of_cfg_option[here] and
 * DPDK 16.07 
 * ASYNC ZMQ is compressed by default. It improves response time see link:http://trex-tgn.cisco.com/youtrack/issue/trex-232[trex-232] 
 ** You will need to update the GUI
-* Support Ubuntu 16.01 - Stateful serverr is Python 3.0 and Python 3.5 for ZMQ library 
+* Support Ubuntu 16.01 - Stateful server is Python 3.0 and Python 3.5 for ZMQ library 
 * XL710/X710 low latency was improved -  see link:http://trex-tgn.cisco.com/youtrack/issue/trex-214[trex-214] 
 * Support graceful shutdown command 
 * Console -  support L1 BPS  using `-m 10bpsl1` see link:http://trex-tgn.cisco.com/youtrack/issue/trex-230[trex-230] 
@@ -906,7 +906,7 @@ For XL710/X710 there is a need to upgrade the firmware to 5.04 (or later)
 ** Add tx/rx graphs 
 * Python API: add an API for reading events as warning/errors
 * HLTAPI support for per stream stats  
-* support VALN mode for per stream stats for 82599 using `--vlan` switch at server invocation
+* support VLAN mode for per stream stats for 82599 using `--vlan` switch at server invocation
 * A peek into TRex stateless GUI version for evaluation still without many features like packet builder, advance packet builder, per stream stats link:https://www.dropbox.com/s/vs9gojtdc5ewv05/setupCiscoTrex1.96-SNAPSHOT.exe?dl=0[TRex Stateless GUI Download]
 ** Only pcap file packet builder is supported in this version 
 
@@ -1103,7 +1103,7 @@ optional arguments:
   -s SPEEDUP, --speedup SPEEDUP
                         Factor to accelerate the injection. effectively means
                         IPG = IPG / SPEEDUP
-  --force               Set if you want to stop active ports before appyling
+  --force               Set if you want to stop active ports before applying
                         command.
 TRex >push -f cap2/dns.pcap  --port 0 -i 10  
 -------------------
@@ -1236,7 +1236,7 @@ TRex > start -f stl/profiles/udp_1pkt.py -a -m 1mbps
 == Release 1.78  ==
 
 * some clean up in tuple generator 
-* trex stateles console works with trex-mock
+* trex stateless console works with trex-mock
 
 === Fixed issues: ===
 

doc/trex_appendix_asa_5585.asciidoc

@@ -8,7 +8,7 @@ TRex with ASA 5585
 
 include::trex_ga.asciidoc[]
 
-When running TRex aginst ASA 5585, you have to notice following things:
+When running TRex against ASA 5585, you have to notice following things:
 
 * ASA can't forward ipv4 options, so there is a need to use --learn-mode 1 (or 3) in case of NAT. In this mode, bidirectional UDP flows are not supported.
 --learn-mode 1 support TCP sequence number randomization in both sides of the connection (client to server and server client). For this to work, TRex must learn

doc/trex_appendix_firmware_xl710.asciidoc

@@ -66,7 +66,7 @@ supports-priv-flags: yes
 <3> Unbind from DPDK using this command
 <4> Bind to linux to i40e driver
 <5> Show firmware version throw linux driver
-<6> Firmare version
+<6> Firmware version
 <7> More info
 
 

doc/trex_appendix_linux_vf_config.asciidoc

@@ -17,7 +17,7 @@ The following diagram compares between vSwitch and SR-IOV.
 
 image:images/sr_iov_vswitch.png[title="vSwitch_main",width=850]
 
-One use case which shows the performance gain that can be acheived by using SR-IOV is when a user wants to create a pool of TRex VMs that tests a pool of virtual DUTs (e.g. ASAv,CSR etc.)
+One use case which shows the performance gain that can be achieved by using SR-IOV is when a user wants to create a pool of TRex VMs that tests a pool of virtual DUTs (e.g. ASAv,CSR etc.)
 When using newly supported SR-IOV, compute, storage and networking resources can be controlled dynamically (e.g by using OpenStack)
 
 image:images/sr_iov_trex.png[title="vSwitch_main",width=850]

doc/trex_appendix_mellanox.asciidoc

@@ -547,7 +547,7 @@ or the new command
 <1>  look for the PCI id
 <2>  run the lspci -vv to find out the Part number
 <3>  Part number  should be MCX516A-CDAT(CX5)/MCX416A-CCAT (CX4) for 100Gb NICS
-<4>  PCI LnkSta (status) should be x16 and *NOT* x8 in case it is not you should look for UCS PCIe configucation (raiser)
+<4>  PCI LnkSta (status) should be x16 and *NOT* x8 in case it is not you should look for UCS PCIe configuration (raiser)
 <5>  Check parent PCI speed to be find where is the problem--> in this case it is 0000:80:03.0
 <6>  Look for the speed
 

doc/trex_astf.asciidoc

@@ -1280,7 +1280,7 @@ We might change the JSON format in the future as this is a first version
 
 *Goal*:: Use the TRex ASTF advanced simulator.
 
-It is like the simple simulator but simulates multiple templates and flows exacly like TRex server would do with one DP core. 
+It is like the simple simulator but simulates multiple templates and flows exactly like TRex server would do with one DP core. 
 
 [source,bash]
 ----
@@ -1552,7 +1552,7 @@ This example will delay the server response by 500 msec.
 
         prog_s = ASTFProgram()
         prog_s.recv(len(http_req))
-        prog_s.delay_rand(100000,500000); # delay random number betwean 100msec-500msec 
+        prog_s.delay_rand(100000,500000); # delay random number between 100msec-500msec 
         prog_s.send(http_response)
         
 ----
@@ -1646,7 +1646,7 @@ Usually in case of very long flows there is need to cap the number of active flo
 
 By default `send()` command waits for the ACK on the last byte. To make it non-blocking, especially in case big BDP (large window is required) it is possible to work in non-blocking mode, this way to achieve full pipeline. 
 
-Have a look at `astf/htttp_eflow2.py` example. 
+Have a look at `astf/http_eflow2.py` example. 
 
 .Non-blocking send 
 [source,python]
@@ -1691,9 +1691,9 @@ Have a look at `astf/htttp_eflow2.py` example.
 See link:cp_astf_docs/api/profile_code.html#astfprogram-class[astf-program] for more info.
 
 ==== Tutorial: L7 emulation - Elephant flows with non-blocking send with tick var
-Same as the previous example, only instead of using `loop count` we are using time as a measurement. In the prevous example we calculated the received bytes in advance and use the rcv command with the right bytes values. However, sending & receiving data according to time is tricky and errors/dtops might occur (see stats from runnnig example below).
+Same as the previous example, only instead of using `loop count` we are using time as a measurement. In the prevous example we calculated the received bytes in advance and use the rcv command with the right bytes values. However, sending & receiving data according to time is tricky and errors/dtops might occur (see stats from running example below).
 
-Have a look at `astf/htttp_eflow4.py` example.
+Have a look at `astf/http_eflow4.py` example.
 
 .Tick var
 [source,python]

doc/trex_astf_vs_nginx.asciidoc

@@ -442,7 +442,7 @@ NGINX installed on a 2-socket setup with 8 cores/socket (total of 16 cores/32 th
 The total number of packets was approximately 600KPPS (Tx+Rx). The number of active flows was 12K.
 
 TRex with one core could scale to about 25Gb/sec, 3MPPS of the same HTTP profile.
-The main issue with NGINX and Linux setup is the tunning. It is very hard to let the hardware utilizing the full server resource (half of the server was idel in this case and still experiance a lot of drop)
+The main issue with NGINX and Linux setup is the tunning. It is very hard to let the hardware utilizing the full server resource (half of the server was idel in this case and still experience a lot of drop)
 TRex is not perfect too, we couldn't reach 100% CPU utilization without a drop (CPU was 84%) need to look if we can improve this but at least we are in the right place for optimization.
 
 Back to our question...

doc/trex_book.asciidoc

@@ -1004,7 +1004,7 @@ TRex port 0 ( server VLAN1) <->  | DUT  | <-> TRex port 1 ( client-VLAN1)
 In this case, traffic on vlan0 is sent as before, while for traffic on vlan1, the order is reversed (client traffic sent on port1 and server traffic on port0).
 TRex divides the flows evenly between the vlans. This results in an equal amount of traffic on each port.
 
-*Router configuation:*::
+*Router configuration:*::
 [source,python]
 ----
         !
@@ -1191,7 +1191,7 @@ asr1k(config)#ipv6 route 5000::/64 3001::2
 <2> Add pbr
 <3> Enable IPv6 routing
 <4> MAC address setting. Should be TRex MAC.
-<5> PBR configuraion
+<5> PBR configuration
 
 
 === Client clustering configuration
@@ -1435,7 +1435,7 @@ For example, in this case 16.0.0.1->48.0.0.1 ICMP will be the flow for latency.
 ==== Clustering example
 
 In this example we have one DUT with four 10gb interfaces and one TRex with two 40Gb/sec interfaces and we want to convert the traffic from 2 TRex interfaces to 4 DUT Interfaces.
-The folowing figure shows the topology
+The following figure shows the topology
 
 .Cluster example
 image:images/cluster_topo1.png[title="Loopback example"]
@@ -1532,14 +1532,14 @@ groups:
 <1> *All* the IPs from client pools and default pool should be maped in this file, it is possible to have wider range  in cluster file
 
 
-The following diagram shows how new flow src_ip/dest_ip/next-hop/vlan is choosen with cluster file
+The following diagram shows how new flow src_ip/dest_ip/next-hop/vlan is chosen with cluster file
 
 .Cluster example
 image:images/new_flow_generation.png[title="Loopback example"]
 
 [NOTE]
 =====================================================================
-Latency stream will check only 12.1.1.1/4050 path (one DUT intertface)  there is no way to check latency on all the ports in current version
+Latency stream will check only 12.1.1.1/4050 path (one DUT interface)  there is no way to check latency on all the ports in current version
 =====================================================================
 
 [NOTE]
@@ -1550,7 +1550,7 @@ DUT should have a static route to move packets from client to server and vice ve
 
 An example of one flow generation
 
-1. next hop resolotion. TRex resolve all the next hop option e.g. 11.10.0.1/4050 11.11.0.1/4051
+1. next hop resolution. TRex resolve all the next hop option e.g. 11.10.0.1/4050 11.11.0.1/4051
 2. Choose template by CPS, 50% probability for each. take template #1
 3. SRC_IP=12.1.1.2, DEST_IP=13.1.1.2
 4. Allocate src_port for 12.1.1.2 ==>src_port=1025 for the first flow of client=12.1.1.2
@@ -1688,7 +1688,7 @@ groups:
 
 
 ----
-<1> We added more clusters beacuse more IPs will be generated (+mask)
+<1> We added more clusters because more IPs will be generated (+mask)
 
 
 
@@ -1827,7 +1827,7 @@ to the command line options, where <sample> is the sample rate. The number of fl
 
 [NOTE]
 ============
-This feature changes the TTL of the sampled flows to 255 and expects to receive packets with TTL 254 or 255 (one routing hop). If you have more than one hop in your setup, use `--hops` to change it to a higher value. More than one hop is possible if there are number of routers betwean TRex client side and TRex server side.
+This feature changes the TTL of the sampled flows to 255 and expects to receive packets with TTL 254 or 255 (one routing hop). If you have more than one hop in your setup, use `--hops` to change it to a higher value. More than one hop is possible if there are number of routers between TRex client side and TRex server side.
 ============
 
 This feature ensures that: