# Assessing the Cloud-RAN in the Linux Kernel: Sharing Computing and Network Resources
## 3 System Model: Instantiating the vBBU within the Linux Kernel
### Sharing Computing Resources with User-Space Workloads and Kernel Threads  
As the vBBU may share computing resources (e.g., CPU time, I/O, memory) with user-space processes and Kernel threads, understanding the impact of such resource sharing on vBBU performance is crucial. To this end, three vBBU execution scenarios are considered.  
The first scenario, denoted _Idle_, involves running the vBBU with no collocated user-space processes or Kernel threads. The second scenario, denoted _User_, entails running the vBBU concurrently with other user-space processes on the same set of CPUs. This setting aims to replicate a situation where the vBBU shares computing resources with non-RT user-space processes. To emulate this, workloads are generated on various subsystems of the edge server. For instance, user-space processes are executed on each CPU, simulating intensive I/O operations, virtual memory stress, disk read/write operations, and message sending/receiving using POSIX. This approach offers a thorough assessment of how the vBBU performs amid the strain of user-space collocated workloads, providing valuable insights into potential challenges and performance implications in real-world scenarios. In the third scenario, named Kernel, the vBBU operates alongside Kernel threads on the same set of CPUs. Kernel threads, serving as entities utilized by the Kernel for CPU-time allocation, are non-preemptive [53]. This characteristic introduces the potential for an impact on vBBU performance if Kernel threads are scheduled on the same CPU [25]. To delve into the influence of Kernel thread processing on vBBU performance, this paper narrows its focus to Hard-IRQs generated when the Linux RT-Kernel receives incoming network packets [54].  
Upon receiving a packet, the network interface card (NIC) driver initiates a Hard-IRQ, signaling the availability of an incoming packet for processing. In situations where there is a high flow of incoming packets to the NIC, a corresponding surge in Hard-IRQs occurs. Handling a large number of Hard-IRQs can monopolize CPU time, potentially resulting in starvation for other processes [55]. To address this, the Linux RT-Kernel uses an adaptive mitigation mechanism known as the New API [56]. NAPI suppresses the generation of Hard-IRQs when the number of incoming packets on the NIC exceeds a pre-defined threshold, known as the NAPI weight. As an alternative, NAPI generates software IRQs [57]. These Soft-IRQs systematically poll and process packets in batches, with the batch size matching the NAPI weight. Furthermore, the NAPI's Soft-IRQ handler runs within the context of the NIC's Hard-IRQ handler (i.e., Kernel thread) that triggers the  
\begin{table}
\begin{tabular}{c c c c} \hline \hline
**Thread** & **Time Requirement** & **Description** & **Index** \\ \hline ru-thread & RT & Radio unit processing & \(\tau_{1}\) \\ \hline lte-softmodem & RT & L1–L2 processing & \(\tau_{2}\) \\ \hline fep\_processing & RT & Front End Process—RX & \(\tau_{3}\) \\ \hline feptx\_thread & RT & Front End Process—TX & \(\tau_{4}\) \\ \hline TASK\_GTPV1\_U & non-RT & GTP tunneling & \(\tau_{5}\) \\ \hline TASK\_UDP & non-RT & UDP socket & \(\tau_{6}\) \\ \hline TASK\_S1 AP & non-RT & S1 channel & \(\tau_{7}\) \\ \hline TASK\_SCTP & non-RT & SCTP channel & \(\tau_{8}\) \\ \hline TASK\_RRC & non-RT & RRC channel & \(\tau_{9}\) \\ \hline \hline \end{tabular}
\end{table}
Table 1: OAI’s LTE–vBBU functions instantiated as threads (subprocesses) in the Linux RT-Kernel.  
Soft-IRQ [54]. When the count of received packets drops below the NAPI weight threshold, the NIC's driver disables the NAPI mechanism and resumes the generation of Hard-IRQs.