23bdac9d7c5ad2a0777547f152a94b7a54f5ad8a
[csit.git] / docs / report / introduction / methodology_nfv_service_density.rst
1 NFV Service Density
2 -------------------
3
4 Network Function Virtualization (NFV) service density tests focus on
5 measuring total per server throughput at varied NFV service “packing”
6 densities with vswitch providing host dataplane. The goal is to compare
7 and contrast performance of a shared vswitch for different network
8 topologies and virtualization technologies, and their impact on vswitch
9 performance and efficiency in a range of NFV service configurations.
10
11 Each NFV service instance consists of a set of Network Functions (NFs),
12 running in VMs (VNFs) or in Containers (CNFs), that are connected into a
13 virtual network topology using VPP vswitch running in Linux user-mode.
14 Multiple service instances share the vswitch that in turn provides per
15 service chain forwarding context(s). In order to provide a most complete
16 picture, each network topology and service configuration is tested in
17 different service density setups by varying two parameters:
18
19 - Number of service instances (e.g. 1,2,4..10).
20 - Number of NFs per service instance (e.g. 1,2,4..10).
21
22 The initial implementation of NFV service density tests in
23 |csit-release| is using two NF applications:
24
25 - VNF: VPP of the same version as vswitch running in KVM VM, configured with /8
26   IPv4 prefix routing.
27 - CNF: VPP of the same version as vswitch running in Docker Container,
28   configured with /8 IPv4 prefix routing. VPP got chosen as a fast IPv4 NF
29   application that supports required memif interface (L3fwd does not). This is
30   similar to all other Container tests in CSIT that use VPP.
31
32 Tests are designed such that in all tested cases VPP vswitch is the most
33 stressed application, as for each flow vswitch is processing each packet
34 multiple times, whereas VNFs and CNFs process each packets only once. To
35 that end, all VNFs and CNFs are allocated enough resources to not become
36 a bottleneck.
37
38 Service Configurations
39 ~~~~~~~~~~~~~~~~~~~~~~
40
41 Following NFV network topologies and configurations are tested:
42
43 - VNF Service Chains (VSC) with L2 vswitch
44
45   - *Network Topology*: Sets of VNFs dual-homed to VPP vswitch over
46     virtio-vhost links. Each set belongs to separate service instance.
47   - *Network Configuration*: VPP L2 bridge-domain contexts form logical
48     service chains of VNF sets and connect each chain to physical
49     interfaces.
50
51 - CNF Service Chains (CSC) with L2 vswitch
52
53   - *Network Topology*: Sets of CNFs dual-homed to VPP vswitch over
54     memif links. Each set belongs to separate service instance.
55   - *Network Configuration*: VPP L2 bridge-domain contexts form logical
56     service chains of CNF sets and connect each chain to physical
57     interfaces.
58
59 - CNF Service Pipelines (CSP) with L2 vswitch
60
61   - *Network Topology*: Sets of CNFs connected into pipelines over a
62     series of memif links, with edge CNFs single-homed to VPP vswitch
63     over memif links. Each set belongs to separate service instance.
64   - *Network Configuration*: VPP L2 bridge-domain contexts connect each
65     CNF pipeline to physical interfaces.
66
67 Thread-to-Core Mapping
68 ~~~~~~~~~~~~~~~~~~~~~~
69
70 CSIT defines specific ratios for mapping software threads of vswitch and
71 VNFs/CNFs to physical cores, with separate ratios defined for main
72 control threads and data-plane threads.
73
74 In |csit-release| NFV service density tests run on Intel Xeon testbeds
75 with Intel Hyper-Threading enabled, so each physical core is associated
76 with a pair of sibling logical cores corresponding to the hyper-threads.
77
78 |csit-release| executes tests with the following software thread to
79 physical core mapping ratios:
80
81 - vSwitch
82
83   - Data-plane on single core
84
85     - (main:core) = (1:1) => 1mt1c - 1 main thread on 1 core.
86     - (data:core) = (1:1) => 2dt1c - 2 Data-plane Threads on 1 Core.
87
88   - Data-plane on two cores
89
90     - (main:core) = (1:1) => 1mt1c - 1 Main Thread on 1 Core.
91     - (data:core) = (1:2) => 4dt2c - 4 Data-plane Threads on 2 Cores.
92
93 - VNF and CNF
94
95   - Data-plane on single core
96
97     - (main:core) = (2:1) => 2mt1c - 2 Main Threads on 1 Core, 1 Thread
98       per NF, core shared between two NFs.
99     - (data:core) = (1:1) => 2dt1c - 2 Data-plane Threads on 1 Core per
100       NF.
101
102   - Data-plane on single logical core (Two NFs per physical core)
103
104     - (main:core) = (2:1) => 2mt1c - 2 Main Threads on 1 Core, 1 Thread
105       per NF, core shared between two NFs.
106     - (data:core) = (2:1) => 1dt1c - 1 Data-plane Threads on 1 Core per
107       NF.
108
109
110 Maximum tested service densities are limited by a number of physical
111 cores per NUMA. |csit-release| allocates cores within NUMA0. Support for
112 multi NUMA tests is to be added in future release.

©2016 FD.io a Linux Foundation Collaborative Project. All Rights Reserved.
Linux Foundation is a registered trademark of The Linux Foundation. Linux is a registered trademark of Linus Torvalds.
Please see our privacy policy and terms of use.