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: DPDK L3fwd running in KVM VM, configured with /8 IPv4 prefix
  26   routing. L3fwd got chosen as a lightweight fast IPv4 VNF application,
  27   and follows CSIT approach of using DPDK sample applications in VMs for
  28   performance testing.
  29 - CNF: VPP running in Docker Container, configured with /24 IPv4 prefix
  30   routing. VPP got chosen as a fast IPv4 NF application that supports
  31   required memif interface (L3fwd does not). This is similar to all
  32   other Container tests in CSIT that use VPP.
  33
  34 Tests are designed such that in all tested cases VPP vswitch is the most
  35 stressed application, as for each flow vswitch is processing each packet
  36 multiple times, whereas VNFs and CNFs process each packets only once. To
  37 that end, all VNFs and CNFs are allocated enough resources to not become
  38 a bottleneck.
  39
  40 Service Configurations
  41 ~~~~~~~~~~~~~~~~~~~~~~
  42
  43 Following NFV network topologies and configurations are tested:
  44
  45 - VNF Service Chains (VSC) with L2 vswitch
  46
  47   - *Network Topology*: Sets of VNFs dual-homed to VPP vswitch over
  48     virtio-vhost links. Each set belongs to separate service instance.
  49   - *Network Configuration*: VPP L2 bridge-domain contexts form logical
  50     service chains of VNF sets and connect each chain to physical
  51     interfaces.
  52
  53 - CNF Service Chains (CSC) with L2 vswitch
  54
  55   - *Network Topology*: Sets of CNFs dual-homed to VPP vswitch over
  56     memif links. Each set belongs to separate service instance.
  57   - *Network Configuration*: VPP L2 bridge-domain contexts form logical
  58     service chains of CNF sets and connect each chain to physical
  59     interfaces.
  60
  61 - CNF Service Pipelines (CSP) with L2 vswitch
  62
  63   - *Network Topology*: Sets of CNFs connected into pipelines over a
  64     series of memif links, with edge CNFs single-homed to VPP vswitch
  65     over memif links. Each set belongs to separate service instance.
  66   - *Network Configuration*: VPP L2 bridge-domain contexts connect each
  67     CNF pipeline to physical interfaces.
  68
  69 Thread-to-Core Mapping
  70 ~~~~~~~~~~~~~~~~~~~~~~
  71
  72 CSIT defines specific ratios for mapping software threads of vswitch and
  73 VNFs/CNFs to physical cores, with separate ratios defined for main
  74 control threads and data-plane threads.
  75
  76 In |csit-release| NFV service density tests run on Intel Xeon testbeds
  77 with Intel Hyper-Threading enabled, so each physical core is associated
  78 with a pair of sibling logical cores corresponding to the hyper-threads.
  79
  80 |csit-release| executes tests with the following software thread to
  81 physical core mapping ratios:
  82
  83 - vSwitch
  84
  85   - Data-plane on single core
  86
  87     - (data:core) = (1:1) => 2dt1c - 2 Data-plane Threads on 1 Core.
  88     - (main:core) = (1:1) => 1mt1c - 1 Main Thread on 1 Core.
  89
  90   - Data-plane on two cores
  91
  92     - (data:core) = (1:2) => 4dt2c - 4 Data-plane Threads on 2 Cores.
  93     - (main:core) = (1:1) => 1mt1c - 1 Main Thread on 1 Core.
  94
  95 - VNF and CNF
  96
  97   - Data-plane on single core
  98
  99     - (data:core) = (1:1) => 2dt1c - 2 Data-plane Threads on 1 Core per
 100       NF.
 101     - (main:core) = (2:1) => 2mt1c - 2 Main Threads on 1 Core, 1 Thread
 102       per NF, core shared between two NFs.
 103
 104 Maximum tested service densities are limited by a number of physical
 105 cores per NUMA. |csit-release| allocates cores within NUMA0. Support for
 106 multi NUMA tests is to be added in future release.