# NetAP: Adaptive Polling Technique for Network Packet Processing in Virtualized Environments
## 3 Design
### Adaptation Using Golden-Section Search
#### 3.4.1 Considerations for Alternative Algorithms
\begin{table}
\begin{tabular}{c c c c c c c c c c} \hline \hline \multicolumn{6}{c}{**(a) After Adapting (90 s-120 s)**} & \multicolumn{6}{c}{**(b) While Adapting (30 s-60 s)**} \\ \hline  & **1 VM-6T** & **2 VM-3T** & **3 VM-2T** & **6 VM-1T** & & **1 VM-6T** & **2 VM-3T** & **3 VM-2T** & **6 VM-1T** \\ \hline
0.25 s & 94.54\% & 102.53\% & 90.23\% & 74.96\% & 0.25 s & 91.15\% & 99.94\% & 92.24\% & 78.91\% \\ \hline
0.5 s & 90.56\% & 101.69\% & 97.91\% & 78.96\% & 0.5 s & 84.44\% & 98.95\% & 95.97\% & 84.00\% \\ \hline
1 s & 100.27\% & 100.15\% & 100.89\% & 80.58\% & 1 s & 94.32\% & 98.76\% & 97.13\% & 81.30\% \\ \hline
2 s & 98.35\% & 102.49\% & 102.19\% & 78.84\% & 2 s & 84.16\% & 94.38\% & 97.98\% & 81.35\% \\ \hline
3 s & 93.55\% & 100.39\% & 98.81\% & 78.44\% & 3 s & 79.58\% & 92.02\% & 98.24\% & 87.28\% \\ \hline
5 s & 98.80\% & 101.59\% & 99.28\% & 88.13\% & 5 s & 65.79\% & 89.90\% & 94.62\% & 85.35\% \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Performance relative to the best bandwidth in Figure 2.

Figure 3: Aggregate bandwidth of VMs with NetAP under the different round lengths. Figure 4 illustrates the aggregate network bandwidth (left y-axis) and the polling interval (right y-axis) of each VM over time. In all scenarios, the aggregate bandwidth increases when NetAP is applied at 20 s. NetAP periodically checks whether there are pending packets for processing before a vIRQ is generated. This procedure prevents expensive VM-Exit and VM-Entry operations and improves the overall network performance. Furthermore, we find that NetAP offers more stable performance than the unmodified VirtIO. In the unmodified VirtIO, a vIRQ to notify the vHost thread can be generated after the corresponding VM is scheduled by the CPU scheduler. Therefore, the vIRQ can be delayed, and this may cause unstable performance. In the figure, the polling interval of each VM varies for approximately 10 s when NetAP is applied. This is because the algorithm searches for the near-optimal polling 11 times for an adaptation. After the near-optimal interval is found, NetAP continuously maintains the interval. In addition, the near-optimal polling interval of each VM varies in Figure 4 when multiple VMs run concurrently. As described in Section 4.1, the reason is that the golden-section searching algorithm is executed in a distributed-manner. Each searching algorithm separately runs per vHost thread during the round. However, NetAP still improves the aggregate bandwidth of VMs by adjusting the polling intervals of each VM independently. Tables 3 and 4 show the aggregate bandwidth, CPU utilization, and latency for every 20 s in each scenario; 0 to 20 s is the time for which unmodified VirtIO runs (VirtIO period), 20 to 40 s is when the algorithm searches for the near-optimal polling interval (Adapting period), and the last 20 s correspond to the time after the near-optimal interval has been applied (Adapted period). First, NetAP in the Adapted period shows that the aggregate bandwidth is improved by up to 30.37% compared to that in the VirtIO period. In each Adapted period, the CPU utilization of the host is decreased compared to that in the VirtIO period because NetAP reduces the number of VM-Exit and VM-Entry operations that occur in the case of the interrupt-based method in the existing VirtIO. In addition, NetAP increases the guest CPU utilization as NetAP processes incoming packets on a timely basis and allows the corresponding VM to generate more packets in the queue. As a result, NetAP achieves improved efficiency in packet processing. Figure 4: Aggregate bandwidth and the polling interval of each VM over time in different experiment scenarios. In addition, end-user latency decreases by up to 89.49%. The standard deviation in the Adapted period also reduces to a maximum level of 40%, and it shows improvement compared to the VirtIO period for all scenarios. From these results, we can assume that the time for delivering vIRQs is variable in the unmodified VirtIO.