docs/design/kvmfornfv_design.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2 .. http://creativecommons.org/licenses/by/4.0
   3
   4 ============
   5 Introduction
   6 ============
   7
   8 **Purpose**:
   9
  10  This document provides an overview of the areas that can be addressed to
  11  enhance the KVM Hypervisor for NFV. It is intended to capture and convey the
  12  significant changes which have been made on the KVM Hypervisor.
  13
  14
  15 ===================
  16 Project description
  17 ===================
  18
  19 The NFV hypervisors provide crucial functionality in the NFV
  20 Infrastructure(NFVI).The existing hypervisors, however, are not necessarily
  21 designed or targeted to meet the requirements for the NFVI.
  22
  23 This design focuses on the enhancement of following area for KVM Hypervisor
  24
  25 * Minimal Interrupt latency variation for data plane VNFs:
  26    * Minimal Timing Variation for Timing correctness of real-time VNFs
  27    * Minimal packet latency variation for data-plane VNFs
  28 * Fast live migration
  29
  30 While these items require software development and/or specific hardware features
  31 there are also some adjustments that need to be made to system configuration
  32 information, like hardware, BIOS, OS, etc.
  33
  34 **Minimal Interrupt latency variation for data plane VNFs**
  35
  36 Processing performance and latency depend on a number of factors, including
  37 the CPUs (frequency, power management features, etc.), micro-architectural
  38 resources, the cache hierarchy and sizes, memory (and hierarchy, such as NUMA)
  39 and speed, inter-connects, I/O and I/O NUMA, devices, etc.
  40
  41 There are two separate types of latencies to minimize:
  42
  43    1. Minimal Timing Variation for Timing correctness of real-time
  44       VNFs – timing correctness for scheduling operations(such as Radio scheduling)
  45    2. Minimal packet latency variation for data-plane VNFs – packet delay
  46       variation, which applies to packet processing.
  47
  48 For a VM, interrupt latency (time between arrival of H/W interrupt and
  49 invocation of the interrupt handler in the VM), for example, can be either of
  50 the above or both, depending on the type of the device. Interrupt latency with
  51 a (virtual) timer can cause timing correctness issues with real-time VNFs even
  52 if they only use polling for packet processing.
  53
  54 We assume that the VNFs are implemented properly to minimize interrupt latency
  55 variation within the VMs, but we have additional causes of latency variation
  56 on KVM:
  57
  58     - Asynchronous (e.g. external interrupts) and synchronous(e.g. instructions)
  59       VM exits and handling in KVM (and kernel routines called), which may have
  60       loops and spin locks
  61     - Interrupt handling in the host Linux and KVM, scheduling and virtual
  62       interrupt delivery to VNFs
  63     - Potential VM exit (e.g. EOI) in the interrupt service routines in VNFs
  64     - Exit to the user-level (e.g. QEMU)
  65
  66 .. Figure:: kvm1.png
  67
  68 =====================
  69 Design Considerations
  70 =====================
  71
  72 The latency variation and jitters can be minimized with the below
  73 steps (with some in parallel):
  74
  75     1. Statically and exclusively assign hardware resources
  76        (CPUs, memory, caches,) to the VNFs.
  77
  78     2. Pre-allocate huge pages (e.g. 1 GB/2MB pages) and guest-to-host mapping,
  79        e.g. EPT (Extended Page Table) page tables, to minimize or mitigate
  80        latency from misses in caches,
  81
  82     3. Use the host Linux configured for hard real-time and packet latency,
  83        Check the set of virtual devices used by the VMs to optimize or
  84        eliminate virtualization overhead if applicable
  85
  86     4. Use advanced hardware virtualization features that can reduce or
  87        eliminate VM exits, if present, and
  88
  89     5. Inspect the code paths in KVM and associated kernel services to
  90        eliminate code that can cause latencies (e.g. loops and spin locks).
  91
  92     6. Measure latencies intensively. We leverage the existing testing methods.
  93        OSADL, for example, defines industry tests for timing correctness.
  94
  95 ====================
  96 Goals and Guidelines
  97 ====================
  98
  99 The output of this project will provide :
 100
 101     1. A list of the performance goals, which will be obtained by the
 102        OPNFV members (as described above)
 103
 104     2. A set of comprehensive instructions for the system configurations
 105        (hardware features, BIOS setup, kernel parameters, VM configuration,
 106        options to QEMU/KVM, etc.)
 107
 108     3. The above features to the upstream of Linux, the real-time patch
 109        set, KVM, QEMU, libvirt, and
 110
 111     4. Performance and interrupt latency measurement tools
 112
 113 =========
 114 Test plan
 115 =========
 116
 117 The tests that need to be conducted to make sure that all components from OPNFV
 118 meet the requirement are mentioned below:
 119
 120 **Timer test**:This test utilize the cyclictest
 121 (https://rt.wiki.kernel.org/index.php/Cyclictest) to test the guest timer
 122 latency (the latency from the time that the guest timer should be triggered
 123 to the time the guest timer is really triggered).
 124
 125 .. Figure:: TimerTest.png
 126
 127 **Device Interrupt Test**:A device on the hardware platform trigger interrupt
 128 every one ms and the device interrupt will be delivered to the VNF. This test
 129 cover the latency from the interrupt happened on the hardware to the time the
 130 interrupt handled in the VNF.
 131
 132 .. Figure:: DeviceInterruptTest.png
 133
 134 **Packet forwarding (DPDK OVS)**:A packet is sent from TC (Traffic Generator)
 135 to a VNF.  The VNF, after processing the packet, forwards the packet to another
 136 NIC and in the end the packet is received by the traffic generator. The test
 137 check the latency from the packet is sent out by the TC to the time the packet
 138 is received by the TC.
 139
 140 .. Figure:: PacketforwardingDPDK_OVS.png
 141
 142 **Packet Forwarding (SR-IOV)**:This test is similar to Packet Forwarding
 143 (DPDK OVS). However, instead of using virtio NIC devices on the guest,
 144 a PCI NIC or a PCI VF NIC is assigned to the guest for network acess.
 145
 146 **Bare-metal Packet Forwarding**:This is used to compare with the above
 147 packet forwarding scenario.
 148
 149 .. Figure:: Bare-metalPacketForwarding.png
 150
 151 =========
 152 Reference
 153 =========
 154
 155 https://wiki.opnfv.org/display/kvm/