ncept of "Processing Cycle Budget Analysis" comes from the digital signal processing (DSP) world, where dimensioning is historically done by dividing the available multi- ply-accumulate capacity of the device (measured often as available CPU clock cycles-number of DSP/CPU cores multiplied by the frequency of operation) between the jobs that need processing. This concept can be carried over to the packet processing world where we define a "cycle budget" as: frequency number of CPU cores Cycle budget per second needed to be processed This defines an available number of clock cycles (the budget) that presents the compute horsepower available to spend on packet processing. For packet forwarding applications, this budget is both well understood/documented and very low. Consider which advertises 233 Gbps (or 347 million packets per second) of L3 forwarding at 64-byte packet sizes on a 28-thread, 2.3 GHz machine, or 28 X 2.3 G/347 M = 186 clocks/packet. Note that such for- warding applications are a very trivial example and do not represent a base station stack. Nonetheless, it establishes a methodology and a categorization of processing complexity: <1000 clocks/packet for packet forwarding/routing applications <10,000 clocks/packet for complex packet operations that include payload manipulation (e.g., Packet Data Convergence Protocol and Radio Link Control-type applications) <100,000 clocks/packet for applications where the payload needs to be interpreted (control plane applications) Again, these are extremely high-level approximations and obviously depend on the pro- cessor architecture as much as on software efficiency and details of the application. The next step is obviously cycle count measurement (and tracking) of the actual applica- tion to establish a more accurate set of metrics. Per-component [and this could be an Application Programming Interface (API) call, a set of API calls or entry/exit points from/to network interfaces] cycle count tracking is implemented by reading the CPU timebase (stop- watch) before