s, SO does the CPU workload and context switching overhead (i.e., overhead associated with storing and restoring the state or context of a process SO that execution can be resumed from the same point at a later time) of CPU cores associated with serving the interrupts. This creates an I/O bottleneck and results in overall performance degradation of the system. A new approach referred to as SR-IOV [7], solves the above issue (this is discussed in Chapter 3). In this approach, the VNF is granted direct access to hardware resources at the network interface level by the hypervisor. SR-IOV allows one to create multiple virtual hardware instances, called Building the Network of the Future SR-IOV 22000 20000 20000 18000 18000 16000 16000 14000 L2FWD 14000 12000 12000 10000 10000 SR-10V SR-10V PKTGEN PKTGEN Frame Size (bytes) Throughput (Mbps) Throughput (kpps) FIGURE 10.11 Performance results with OVS DPDK. VFs of the pNIC (or in SR-IOV terminology, the physical function or PF) such that multiple VNFs can each be assigned a VF and share the same PF (or pNIC.) As the packet arrives at the network interface, it is directly placed into the hardware (HW) queue associated with the specific VNF, based on destination MAC or VLAN tag. Subsequently, as the CPU tied to the VNF is ready to process the next packet, it can be directly accessed using direct memory access (DMA). SR-IOV essentially provides an optimized environment where packets are not copied multiple times before it can be processed by the VNF. Figure 10.11 provides the topology and performance results associated with SR-IOV-based approach. While SR-IOV provides better performance in terms of processing traffic at a higher rate, it may not be a suitable implementation for all cases. Implementation of SR-IOV is essentially a tradeoff between higher performance and feature-functionality. For example, since in SR-IOV, the VNF is directly tied to hardware, dynamic VNF mobility (i.e., moving a VNF to another server) is not possible. In addition, one also loses the capabil