Apply minor improvements to methodology docs

Change-Id: Ice5625c2b04dce174b19748b0ccccdf813b66f2a
Signed-off-by: Vratko Polak <vrpolak@cisco.com>

diff --git a/docs/report/introduction/methodology_bmrr_throughput.rst b/docs/report/introduction/methodology_bmrr_throughput.rst
index ac3c54e..7bef3a4 100644 (file)
--- a/docs/report/introduction/methodology_bmrr_throughput.rst
+++ b/docs/report/introduction/methodology_bmrr_throughput.rst
@@ -19,7 +19,7 @@ Current parameters for BMRR tests:
   quoted sizes include frame CRC, but exclude per frame transmission
   overhead of 20B (preamble, inter frame gap).
 
   quoted sizes include frame CRC, but exclude per frame transmission
   overhead of 20B (preamble, inter frame gap).
 

-- Maximum load offered: 10GE and 40GE link (sub-)rates depending on NIC
+- Maximum load offered: 10GE, 25GE and 40GE link (sub-)rates depending on NIC

   tested, with the actual packet rate depending on frame size,
   transmission overhead and traffic generator NIC forwarding capacity.
 
   tested, with the actual packet rate depending on frame size,
   transmission overhead and traffic generator NIC forwarding capacity.
 


@@ -37,8 +37,8 @@ Current parameters for BMRR tests:
 
 - Number of trials per burst: 10.
 
 
 - Number of trials per burst: 10.
 

-Similarly to NDR/PDR throughput tests, MRR test should be reporting bi-
-directional link rate (or NIC rate, if lower) if tested VPP
+Similarly to NDR/PDR throughput tests, MRR test should be reporting
+bi-directional link rate (or NIC rate, if lower) if tested VPP

 configuration can handle the packet rate higher than bi-directional link
 rate, e.g. large packet tests and/or multi-core tests.
 
 configuration can handle the packet rate higher than bi-directional link
 rate, e.g. large packet tests and/or multi-core tests.
 

diff --git a/docs/report/introduction/methodology_multi_core_speedup.rst b/docs/report/introduction/methodology_multi_core_speedup.rst
index 9484040..b42bf42 100644 (file)
--- a/docs/report/introduction/methodology_multi_core_speedup.rst
+++ b/docs/report/introduction/methodology_multi_core_speedup.rst
@@ -51,7 +51,7 @@ In all CSIT tests care is taken to ensure that each VPP worker handles
 the same amount of received packet load and does the same amount of
 packet processing work. This is achieved by evenly distributing per
 interface type (e.g. physical, virtual) receive queues over VPP workers
 the same amount of received packet load and does the same amount of
 packet processing work. This is achieved by evenly distributing per
 interface type (e.g. physical, virtual) receive queues over VPP workers

-using default VPP round- robin mapping and by loading these queues with
+using default VPP round-robin mapping and by loading these queues with

 the same amount of packet flows.
 
 If number of VPP workers is higher than number of physical or virtual
 the same amount of packet flows.
 
 If number of VPP workers is higher than number of physical or virtual


@@ -62,5 +62,5 @@ for virtual interfaces are used for this purpose.
 Section :ref:`throughput_speedup_multi_core` includes a set of graphs
 illustrating packet throughout speedup when running VPP worker threads
 on multiple cores. Note that in quite a few test cases running VPP
 Section :ref:`throughput_speedup_multi_core` includes a set of graphs
 illustrating packet throughout speedup when running VPP worker threads
 on multiple cores. Note that in quite a few test cases running VPP

-workers on 2 or 4 physical cores hits the I/O bandwidth or packets-per-
-second limit of tested NIC.
+workers on 2 or 4 physical cores hits the I/O bandwidth
+or packets-per-second limit of tested NIC.

diff --git a/docs/report/introduction/methodology_nfv_service_density.rst b/docs/report/introduction/methodology_nfv_service_density.rst
index 2946ba2..51e56e2 100644 (file)
--- a/docs/report/introduction/methodology_nfv_service_density.rst
+++ b/docs/report/introduction/methodology_nfv_service_density.rst
@@ -103,4 +103,4 @@ physical core mapping ratios:
 
 Maximum tested service densities are limited by a number of physical
 cores per NUMA. |csit-release| allocates cores within NUMA0. Support for
 
 Maximum tested service densities are limited by a number of physical
 cores per NUMA. |csit-release| allocates cores within NUMA0. Support for

-multi NUMA tests is to be added in future release.
\ No newline at end of file
+multi NUMA tests is to be added in future release.

diff --git a/docs/report/introduction/methodology_packet_latency.rst b/docs/report/introduction/methodology_packet_latency.rst
index 550d12f..411fe3d 100644 (file)
--- a/docs/report/introduction/methodology_packet_latency.rst
+++ b/docs/report/introduction/methodology_packet_latency.rst
@@ -12,8 +12,8 @@ Reported latency values are measured using following methodology:
 - TG reports min/avg/max latency values per stream direction, hence two
   sets of latency values are reported per test case; future release of
   TRex is expected to report latency percentiles.
 - TG reports min/avg/max latency values per stream direction, hence two
   sets of latency values are reported per test case; future release of
   TRex is expected to report latency percentiles.

-- Reported latency values are aggregate across two SUTs due to three
-  node topology used for all performance tests; for per SUT latency,
+- Reported latency values are aggregate across two SUTs if the three
+  node topology is used for given performance test; for per SUT latency,

   reported value should be divided by two.
 - 1usec is the measurement accuracy advertised by TRex TG for the setup
   used in FD.io labs used by CSIT project.
   reported value should be divided by two.
 - 1usec is the measurement accuracy advertised by TRex TG for the setup
   used in FD.io labs used by CSIT project.

diff --git a/docs/report/introduction/methodology_trex_traffic_generator.rst b/docs/report/introduction/methodology_trex_traffic_generator.rst
index 4d4de96..2a25931 100644 (file)
--- a/docs/report/introduction/methodology_trex_traffic_generator.rst
+++ b/docs/report/introduction/methodology_trex_traffic_generator.rst
@@ -6,9 +6,8 @@ Usage
 
 `TRex traffic generator <https://wiki.fd.io/view/TRex>`_ is used for all
 CSIT performance tests. TRex stateless mode is used to measure NDR and
 
 `TRex traffic generator <https://wiki.fd.io/view/TRex>`_ is used for all
 CSIT performance tests. TRex stateless mode is used to measure NDR and

-PDR throughputs using binary search (NDR and PDR discovery tests) and
-for quick checks of DUT performance against the reference NDRs (NDR
-check tests) for specific configuration.
+PDR throughputs using MLRsearch and to measure maximum transer rate
+in MRR tests.

 
 TRex is installed and run on the TG compute node. The typical procedure
 is:
 
 TRex is installed and run on the TG compute node. The typical procedure
 is:

diff --git a/docs/report/introduction/methodology_tunnel_encapsulations.rst b/docs/report/introduction/methodology_tunnel_encapsulations.rst
index 6c47d1b..d9e2f42 100644 (file)
--- a/docs/report/introduction/methodology_tunnel_encapsulations.rst
+++ b/docs/report/introduction/methodology_tunnel_encapsulations.rst
@@ -15,7 +15,7 @@ VPP is tested in the following IPv4 tunnel baseline configurations:
 - *ip4lispip4-ip4base*: LISP over IPv4 tunnels with IPv4 routing.
 - *ip4lispip6-ip6base*: LISP over IPv4 tunnels with IPv6 routing.
 
 - *ip4lispip4-ip4base*: LISP over IPv4 tunnels with IPv4 routing.
 - *ip4lispip6-ip6base*: LISP over IPv4 tunnels with IPv6 routing.
 

-In all cases listed above low number of MAC, IPv4, IPv6 flows (253 per
+In all cases listed above low number of MAC, IPv4, IPv6 flows (254 or 253 per

 direction) is switched or routed by VPP.
 
 In addition selected IPv4 tunnels are tested at scale:
 direction) is switched or routed by VPP.
 
 In addition selected IPv4 tunnels are tested at scale:

diff --git a/docs/report/introduction/methodology_vpp_forwarding_modes.rst b/docs/report/introduction/methodology_vpp_forwarding_modes.rst
index 6cf206f..1af3a46 100644 (file)
--- a/docs/report/introduction/methodology_vpp_forwarding_modes.rst
+++ b/docs/report/introduction/methodology_vpp_forwarding_modes.rst
@@ -21,8 +21,8 @@ VPP is tested in three L2 forwarding modes:
 
 l2bd tests are executed in baseline and scale configurations:
 
 
 l2bd tests are executed in baseline and scale configurations:
 

-- *l2bdbase*: low number of L2 flows (253 per direction) is switched by
-  VPP. They drive the content of MAC FIB size (506 total MAC entries).
+- *l2bdbase*: low number of L2 flows (254 per direction) is switched by
+  VPP. They drive the content of MAC FIB size (508 total MAC entries).

   Both source and destination MAC addresses are incremented on a packet
   by packet basis.
 
   Both source and destination MAC addresses are incremented on a packet
   by packet basis.
 


@@ -40,8 +40,8 @@ IPv4 Routing
 
 IPv4 routing tests are executed in baseline and scale configurations:
 
 
 IPv4 routing tests are executed in baseline and scale configurations:
 

-- *ip4base*: low number of IPv4 flows (253 per direction) is routed by
-  VPP. They drive the content of IPv4 FIB size (506 total /32 prefixes).
+- *ip4base*: low number of IPv4 flows (253 or 254 per direction) is routed by
+  VPP. They drive the content of IPv4 FIB size (506 or 508 total /32 prefixes).

   Destination IPv4 addresses are incremented on a packet by packet
   basis.
 
   Destination IPv4 addresses are incremented on a packet by packet
   basis.
 


@@ -57,8 +57,8 @@ IPv6 Routing
 
 IPv6 routing tests are executed in baseline and scale configurations:
 
 
 IPv6 routing tests are executed in baseline and scale configurations:
 

-- *ip6base*: low number of IPv6 flows (253 per direction) is routed by
-  VPP. They drive the content of IPv6 FIB size (506 total /128 prefixes).
+- *ip6base*: low number of IPv6 flows (253 or 254 per direction) is routed by
+  VPP. They drive the content of IPv6 FIB size (506 or 508 total /128 prefixes).

   Destination IPv6 addresses are incremented on a packet by packet
   basis.
 
   Destination IPv6 addresses are incremented on a packet by packet
   basis.
 

diff --git a/docs/report/introduction/methodology_vpp_startup_settings.rst b/docs/report/introduction/methodology_vpp_startup_settings.rst
index 16185b4..2b0f485 100644 (file)
--- a/docs/report/introduction/methodology_vpp_startup_settings.rst
+++ b/docs/report/introduction/methodology_vpp_startup_settings.rst
@@ -19,7 +19,7 @@ List of vpp startup.conf settings applied to all tests:
    Typically needed for use faster vector PMDs (together with
    no-multi-seg).
 #. socket-mem <value>,<value> - memory per numa. (Not required anymore
    Typically needed for use faster vector PMDs (together with
    no-multi-seg).
 #. socket-mem <value>,<value> - memory per numa. (Not required anymore

-   due to VPP code changes, should be removed in CSIT-18.10.)
+   due to VPP code changes, will be removed in CSIT-19.04.)

 
 Per Test Settings
 ~~~~~~~~~~~~~~~~~
 
 Per Test Settings
 ~~~~~~~~~~~~~~~~~