aboutsummaryrefslogtreecommitdiffstats
path: root/docs/report/vpp_performance_tests/csit_release_notes.rst
blob: fb5737c4fc86a4cf8767dd9bf6703c4031e85a62 (plain) 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131

CSIT Release Notes
==================

Changes in CSIT |release|
-------------------------

#. **VPP performance tests**

   - *MRR tests* - New Maximum Receive Rate tests measure the packet
     forwarding rate under the maximum load offered by traffic
     generator over a set trial duration, regardless of packet loss.
     MRR tests are used for continuous performance trending and for
     comparison between releases.

   - *Service Chaining with SRv6* - New SRv6 (Segment Routing IPv6) proxy
     tests measure performance of SRv6 Endpoint fronting SR-unaware
     appliance via masquerading (End.AM), dynamic proxy (End.AD) or
     static proxy (End.AS) SR functions.

#. **Presentation and Analytics Layer**

   - *Performance trending* - Added continuous performance trending and
     analysis. New Performance Trending and Performance Analysis jobs
     executed regular throughput tests, with results being subsequently
     analysed and trend and anomalies summarized and presented in VPP
     Performance Dashboard and trendline graphs.

#. **Test Framework Optimizations**

   - *Performance tests efficiency* - Qemu build/install optimizations,
     warmup phase handling, vpp restart handling. Resulted in improved
     stability and reduced total execution time by 30% for single pkt
     size e.g. 64B/78B.

   - *General code housekeeping* - ongoing RF keywords optimizations,
     removal of redundant RF keywords.

Performance Changes
-------------------

Relative performance changes in measured packet throughput in CSIT
|release| are calculated against the results from CSIT |release-1|
report. Listed mean and standard deviation values are computed based on
a series of the same tests executed against respective VPP releases to
verify test results repeatibility, with percentage change calculated for
mean values. Note that the standard deviation is quite high for a small
number of packet throughput tests, what indicates poor test results
repeatability and makes the relative change of mean throughput value not
fully representative for these tests. The root causes behind poor
results repeatibility vary between the test cases.

NDR Changes
~~~~~~~~~~~

NDR small packet throughput changes between releases are available in a
CSV and pretty ASCII formats:

  - `csv format for 1t1c <../_static/vpp/performance-changes-ndr-1t1c-full.csv>`_,
  - `csv format for 2t2c <../_static/vpp/performance-changes-ndr-2t2c-full.csv>`_,
  - `pretty ASCII format for 1t1c <../_static/vpp/performance-changes-ndr-1t1c-full.txt>`_,
  - `pretty ASCII format for 2t2c <../_static/vpp/performance-changes-ndr-2t2c-full.txt>`_.

PDR Changes
~~~~~~~~~~~

NDR small packet throughput changes between releases are available in a
CSV and pretty ASCII formats:

  - `csv format for 1t1c <../_static/vpp/performance-changes-pdr-1t1c-full.csv>`_,
  - `csv format for 2t2c <../_static/vpp/performance-changes-pdr-2t2c-full.csv>`_,
  - `pretty ASCII format for 1t1c <../_static/vpp/performance-changes-pdr-1t1c-full.txt>`_,
  - `pretty ASCII format for 2t2c <../_static/vpp/performance-changes-pdr-2t2c-full.txt>`_.

MRR Changes
~~~~~~~~~~~

MRR small packet throughput changes between releases are available in a
CSV and pretty ASCII formats:

  - `csv format for 1t1c <../_static/vpp/performance-changes-mrr-1t1c-full.csv>`_,
  - `csv format for 2t2c <../_static/vpp/performance-changes-mrr-2t2c-full.csv>`_,
  - `csv format for 4t4c <../_static/vpp/performance-changes-mrr-4t4c-full.csv>`_,
  - `pretty ASCII format for 1t1c <../_static/vpp/performance-changes-mrr-1t1c-full.txt>`_,
  - `pretty ASCII format for 2t2c <../_static/vpp/performance-changes-mrr-2t2c-full.txt>`_,
  - `pretty ASCII format for 4t4c <../_static/vpp/performance-changes-mrr-4t4c-full.txt>`_.

Throughput Trending
-------------------

In addition to reporting throughput changes between VPP releases, CSIT
provides continuous performance trending for VPP master branch:

#. `VPP Performance Dashboard <https://docs.fd.io/csit/master/trending/introduction/index.html>`_
   - per VPP test case throughput trend, trend compliance and summary of
   detected anomalies.

#. `Trending Methodology <https://docs.fd.io/csit/master/trending/methodology/index.html>`_
   - throughput test metrics, trend calculations and anomaly
   classification (progression, regression, outlier).

#. `Trendline Graphs <https://docs.fd.io/csit/master/trending/trending/index.html>`_
   - per VPP build MRR throughput measurements against the trendline
   with anomaly highlights, with associated CSIT test jobs.

Known Issues
------------

List of known issues in CSIT |release| for VPP performance tests:

+---+-------------------------------------------------+------------+-----------------------------------------------------------------+
| # | Issue                                           | Jira ID    | Description                                                     |
+===+=================================================+============+=================================================================+
| 1 | Sporadic (1 in 200) NDR discovery test failures | CSIT-570   | DPDK reporting rx-errors, indicating L1 issue. Suspected issue  |
|   | on x520.                                        |            | with HW combination of X710-X520 in LF testbeds. Not observed   |
|   |                                                 |            | outside of LF testbeds.                                         |
+---+-------------------------------------------------+------------+-----------------------------------------------------------------+
| 2 | Lower than expected NDR throughput of DPDK      | CSIT-571   | Suspected NIC firmware or DPDK driver issue affecting NDR and   |
|   | testpmd and VPP L2 path NDR throughput with     |            | PDR throughput on XL710 and X710 NICs.                          |
|   | xl710 and x710 NICs, compared to x520 NICs.     |            |                                                                 |
+---+-------------------------------------------------+------------+-----------------------------------------------------------------+
| 3 | Tagged Ethernet dot1q and dot1ad L2 path        | CSIT-1066  | Tagged Ethernet dot1q and dot1ad L2 path throughput regression: |
|   | throughput regression.                          |            | NDR -2%..-5%, PDR -2%..-6%, MRR. Affects l2xc and l2bd          |
|   |                                                 |            | performance tests.                                              |
+---+-------------------------------------------------+------------+-----------------------------------------------------------------+
| 4 | IPSec (software, no QAT HW) throughput          | CSIT-1064  | IPSec throughput regression: NDR -3%..-8%, PDR -2%..-8%, MRR    |
|   | regression.                                     |            | -3%..-7%. Affects IPSec SW tests, QAT HW tests not affected.    |
+---+-------------------------------------------------+------------+-----------------------------------------------------------------+
| 5 | High failure rate of creating working container | CSIT-1065  | Orchestrated container topology tests failing data plane        |
|   | topologies with K8s/Ligato orchestration.       |            | verification indicating configuration issue. Suspected issue    |
|   |                                                 |            | with Ligato vpp-agent.                                          |
+---+-------------------------------------------------+------------+-----------------------------------------------------------------+
} break; } } return (s); } int fib_path_ext_cmp (fib_path_ext_t *path_ext, const fib_route_path_t *rpath) { return (fib_route_path_cmp(&path_ext->fpe_path, rpath)); } static fib_path_list_walk_rc_t fib_path_ext_match (fib_node_index_t pl_index, fib_node_index_t path_index, void *ctx) { fib_path_ext_t *path_ext = ctx; if (!fib_path_cmp_w_route_path(path_index, &path_ext->fpe_path)) { path_ext->fpe_path_index = path_index; return (FIB_PATH_LIST_WALK_STOP); } return (FIB_PATH_LIST_WALK_CONTINUE); } void fib_path_ext_resolve (fib_path_ext_t *path_ext, fib_node_index_t path_list_index) { /* * Find the path on the path list that this is an extension for */ path_ext->fpe_path_index = FIB_NODE_INDEX_INVALID; fib_path_list_walk(path_list_index, fib_path_ext_match, path_ext); } static void fib_path_ext_init (fib_path_ext_t *path_ext, fib_node_index_t path_list_index, fib_path_ext_type_t ext_type, const fib_route_path_t *rpath) { path_ext->fpe_path = *rpath; path_ext->fpe_path_index = FIB_NODE_INDEX_INVALID; path_ext->fpe_adj_flags = FIB_PATH_EXT_ADJ_FLAG_NONE; path_ext->fpe_type = ext_type; fib_path_ext_resolve(path_ext, path_list_index); } /** * @brief Return true if the label stack is implicit null */ static int fib_path_ext_is_imp_null (fib_path_ext_t *path_ext) { return ((1 == vec_len(path_ext->fpe_label_stack)) && (MPLS_IETF_IMPLICIT_NULL_LABEL == path_ext->fpe_label_stack[0])); } load_balance_path_t * fib_path_ext_stack (fib_path_ext_t *path_ext, fib_forward_chain_type_t child_fct, fib_forward_chain_type_t imp_null_fct, load_balance_path_t *nhs) { fib_forward_chain_type_t parent_fct; load_balance_path_t *nh; if (!fib_path_is_resolved(path_ext->fpe_path_index)) return (nhs); /* * Since we are stacking this path-extension, it must have a valid out * label. From the chain type request by the child, determine what * chain type we will request from the parent. */ switch (child_fct) { case FIB_FORW_CHAIN_TYPE_MPLS_EOS: { /* * The EOS chain is a tricky since, when the path has an imp NULL one cannot know * the adjacency to link to without knowing what the packets payload protocol * will be once the label is popped. */ if (fib_path_ext_is_imp_null(path_ext)) { parent_fct = imp_null_fct; } else { /* * we have a label to stack. packets will thus be labelled when * they encounter the child, ergo, non-eos. */ parent_fct = FIB_FORW_CHAIN_TYPE_MPLS_NON_EOS; } break; } case FIB_FORW_CHAIN_TYPE_UNICAST_IP4: case FIB_FORW_CHAIN_TYPE_UNICAST_IP6: if (fib_path_ext_is_imp_null(path_ext)) { /* * implicit-null label for the eos or IP chain, need to pick up * the IP adj */ parent_fct = child_fct; } else { /* * we have a label to stack. packets will thus be labelled when * they encounter the child, ergo, non-eos. */ parent_fct = FIB_FORW_CHAIN_TYPE_MPLS_NON_EOS; } break; case FIB_FORW_CHAIN_TYPE_MPLS_NON_EOS: parent_fct = child_fct; break; case FIB_FORW_CHAIN_TYPE_ETHERNET: parent_fct = FIB_FORW_CHAIN_TYPE_MPLS_NON_EOS; break; default: return (nhs); break; } dpo_id_t via_dpo = DPO_INVALID; /* * The next object in the graph after the imposition of the label * will be the DPO contributed by the path through which the packets * are to be sent. We stack the MPLS Label DPO on this path DPO */ fib_path_contribute_forwarding(path_ext->fpe_path_index, parent_fct, &via_dpo); if (dpo_is_drop(&via_dpo) || load_balance_is_drop(&via_dpo)) { /* * don't stack a path extension on a drop. doing so will create * a LB bucket entry on drop, and we will lose a percentage of traffic. */ } else { vec_add2(nhs, nh, 1); nh->path_weight = fib_path_get_weight(path_ext->fpe_path_index); nh->path_index = path_ext->fpe_path_index; dpo_copy(&nh->path_dpo, &via_dpo); /* * The label is stackable for this chain type * construct the mpls header that will be imposed in the data-path */ if (!fib_path_ext_is_imp_null(path_ext)) { /* * we use the parent protocol for the label so that * we pickup the correct MPLS imposition nodes to do * ip[46] processing. */ dpo_proto_t chain_proto; mpls_eos_bit_t eos; index_t mldi; eos = (child_fct == FIB_FORW_CHAIN_TYPE_MPLS_NON_EOS ? MPLS_NON_EOS : MPLS_EOS); chain_proto = fib_forw_chain_type_to_dpo_proto(child_fct); mldi = mpls_label_dpo_create(path_ext->fpe_label_stack, eos, 255, 0, chain_proto, &nh->path_dpo); dpo_set(&nh->path_dpo, DPO_MPLS_LABEL, chain_proto, mldi); } } dpo_reset(&via_dpo); return (nhs); } fib_path_ext_t * fib_path_ext_list_find (const fib_path_ext_list_t *list, fib_path_ext_type_t ext_type, const fib_route_path_t *rpath) { fib_path_ext_t *path_ext; vec_foreach(path_ext, list->fpel_exts) { if ((path_ext->fpe_type == ext_type) && !fib_path_ext_cmp(path_ext, rpath) ) { return (path_ext); } } return (NULL); } fib_path_ext_t * fib_path_ext_list_find_by_path_index (const fib_path_ext_list_t *list, fib_node_index_t path_index) { fib_path_ext_t *path_ext; vec_foreach(path_ext, list->fpel_exts) { if (path_ext->fpe_path_index == path_index) { return (path_ext); } } return (NULL); } fib_path_ext_t * fib_path_ext_list_push_back (fib_path_ext_list_t *list, fib_node_index_t path_list_index, fib_path_ext_type_t ext_type, const fib_route_path_t *rpath) { fib_path_ext_t *path_ext; path_ext = fib_path_ext_list_find(list, ext_type, rpath); if (NULL == path_ext) { vec_add2(list->fpel_exts, path_ext, 1); fib_path_ext_init(path_ext, path_list_index, ext_type, rpath); } return (path_ext); } /* * insert, sorted, a path extension to the entry's list. * It's not strictly necessary to sort the path extensions, since each * extension has the path index to which it resolves. However, by being * sorted the load-balance produced has a deterministic order, not an order * based on the sequence of extension additions. this is a considerable benefit. */ fib_path_ext_t * fib_path_ext_list_insert (fib_path_ext_list_t *list, fib_node_index_t path_list_index, fib_path_ext_type_t ext_type, const fib_route_path_t *rpath) { fib_path_ext_t new_path_ext, *path_ext; int i = 0; if (0 == fib_path_ext_list_length(list)) { return (fib_path_ext_list_push_back(list, path_list_index, ext_type, rpath)); } fib_path_ext_init(&new_path_ext, path_list_index, ext_type, rpath); vec_foreach(path_ext, list->fpel_exts) { int res = fib_path_ext_cmp(path_ext, rpath); if (0 == res) { /* * don't add duplicate extensions. modify instead */ vec_free(path_ext->fpe_label_stack); *path_ext = new_path_ext; goto done; } else if (res < 0) { i++; } else { break; } } vec_insert_elts(list->fpel_exts, &new_path_ext, 1, i); done: return (&(list->fpel_exts[i])); } void fib_path_ext_list_resolve (fib_path_ext_list_t *list, fib_node_index_t path_list_index) { fib_path_ext_t *path_ext; vec_foreach(path_ext, list->fpel_exts) { fib_path_ext_resolve(path_ext, path_list_index); }; } void fib_path_ext_list_remove (fib_path_ext_list_t *list, fib_path_ext_type_t ext_type, const fib_route_path_t *rpath) { fib_path_ext_t *path_ext; path_ext = fib_path_ext_list_find(list, ext_type, rpath); if (NULL != path_ext) { /* * delete the element moving the remaining elements down 1 position. * this preserves the sorted order. */ vec_free(path_ext->fpe_label_stack); vec_delete(list->fpel_exts, 1, (path_ext - list->fpel_exts)); } } void fib_path_ext_list_flush (fib_path_ext_list_t *list) { fib_path_ext_t *path_ext; vec_foreach(path_ext, list->fpel_exts) { vec_free(path_ext->fpe_label_stack); }; vec_free(list->fpel_exts); list->fpel_exts = NULL; } u8* format_fib_path_ext_list (u8 * s, va_list * args) { fib_path_ext_list_t *list; fib_path_ext_t *path_ext; list = va_arg (*args, fib_path_ext_list_t *); if (fib_path_ext_list_length(list)) { s = format(s, " Extensions:"); vec_foreach(path_ext, list->fpel_exts) { s = format(s, "\n %U", format_fib_path_ext, path_ext); }; } return (s); } int fib_path_ext_list_length (const fib_path_ext_list_t *list) { return (vec_len(list->fpel_exts)); }