# A Forwarding Latency Optimization Method for Software Data Plane Based on Spin-Polling
## 3 Motivation
### Static Batch Size  
The \(\theta_{Rx}\) and \(\theta_{Tx}\) are usually configured as startup parameters and are therefore static parameters during program execution. Therefore, this section discusses the premise that \(\theta_{Rx}\) and \(\theta_{Tx}\) are fixed values unless otherwise specified.  
As mentioned earlier, \(\theta_{Rx}\) is an upper limit value, and \(\theta_{Tx}\) is a threshold value. The difference in the definitions of \(\theta_{Rx}\) and \(\theta_{Tx}\) determines the behavior of the CPU core on the Rx queues and the Tx queues. To understand the effect of these two batch sizes on the data plane, we first start with data plane performance metrics. Regarding performance indicators, we generally focus on the maximum throughput of the data plane and the forwarding latency. The maximum throughput of the data plane generally refers to the maximum number of packets per second that can be transmitted _without any error_. The forwarding latency generally refers to the time required for a packet to travel from the originating device through the data plane to the destination device. Note that each CPU core has a limited number of cycles per second, so the fewer the cycles it takes to process a packet on average, the higher the throughput. When the traffic load is heavy, the CPU core has a high probability of directly receiving \(\theta_{Rx}\) packets each time it checks an Rx queue. Meanwhile, the number of packets in the Tx queues has a high probability of reaching \(\theta_{Tx}\). Therefore, in the case of heavy traffic load, the batch processing mechanisms can reduce the amortized overhead of a single packet, allowing the data plane to achieve high throughput performance.  
On the other hand, when the traffic load is not so heavy (for example, below 90% load), the number of packets in the queues is likely to be less than \(\theta_{Rx}\) each time the CPU core checks the Rx queues. However, the CPU core will still receive and process these packets, although doing so will increase the amortized overhead. Note that in a spin-polling system, the CPU cores always run full-tilt regardless of the traffic load. Therefore, the packet processing performance of the spin-polling system is excessive in the case of a low traffic load. From this point of view, the increased overhead is a reasonable use of CPU resources. At the same time, the CPU cores process and forward the packets in the Rx queues in time, which can prevent the packets from staying on the data plane device for a longer time. When the traffic load is light for Tx queues, the probability of the number of packets in the queues reaching \(\theta_{Tx}\) is not high, so the packets need to wait in the queues. We mentioned earlier that the batch processing mechanism uses a counter to deal with this situation. Nevertheless, we still notice that the existing batch processing mechanism cannot perfectly cope with different traffic input rates, mainly reflected in the forwarding latency of the software data plane. In the next section, we design experiments to investigate the effect of batch processing mechanisms on the performance of the software data planes.