eeper analysis of packets requires dedicated CPU resources. In order to get extremely high performance, DPDK uses a poll-mode driver instead of an inter- rupt mode driver. A poll-mode driver constantly checks the receive (RX) queues of the interfaces for packets arriving, whereas an interrupt mode driver will notify the CPU via an interrupt that a packet has arrived and needs processing. The interrupt-mode driver takes longer to complete and also causes additional CPU process of the interrupt. Because the poll mode driver is constantly checking the RX queues, the entire CPU can be consumed even if there is no traffic to process. This is not an issue for networking VNFs that constantly have a high rate of traffic to process, such as core or aggregation routers, for VNFs that have a light load of traffic this leads to CPU ineffi- ciency-the wasted CPU cycles could have been used by other VNFs on the same server to process traffic. In order to address this, DPDK. org as well as vendors have started to introduce optimiza- tions and tuning to create an "adaptive" poll-mode driver [6]. The adaptive poll mode driver can adjust the frequency of polling based on the observed traffic load, SO that when lighter loads are seen, polling is less frequent. 10.2.3.3 SR-IOV-Based Approach The Linux bridge and standard OVS approach focuses on switching the packets within the host to different VNFs based on destination MAC address or VLAN tag. With both of these approaches, every packet transmitted or received has to be processed by the hypervisor as it gets copied from the NIC to the VNF memory space, and also processed by the Linux bridge (or virtual switch) in order to make the switching decision. Processing of each packet typically requires the CPU to service three interrupts-one to handle the packet as it arrives to the host pNIC and send it to the Linux bridge or OVS, a second to make a switching decision, and a third to take the packet from the vNIC to into VNF memory space for processing. As the packet arrival rate increase