 and a tracking mechanism to make sure that reality matches to theory-or that appropriate mitigation measures can be taken. Let's build mindset of performance-aware design and system architecture. This includes planning mea- surement experiments to ensure that results are both representative and reproducible. Software also needs to be instrumented to facilitate data collection. Finally, once the performance-critical components of the software are identified, they are measured early and often to validate the models that have been built and to verify earlier predictions. Note that for the purpose of such benchmarks, it is useful to identify a few "key" use cases (centering around bitrate, packet rate, user count, etc.). Performance metrics are divided into three categories, each of them tackling separate areas of the performance pic- ture, which are as follows: cycle counts per SW component or Processing Cycle Budget Analysis Central Processing Unit (CPU) loading summaries System-on-Chip (SoC) performance counters We can also break performance aspects down to use-case components: L2/stack performance-including Enhanced Common Public Radio Interface (eCPRI) as an example of an packetization protocol potentially running under Linux L1/Physical Layer performance accelerator/offload-associated overheads Each of these components are broken down in more detail later in this chapter. We also discuss performance mitigation techniques: what can we do when achieved performance does not match to the target and we need to deploy a product into the market anyway? All components of the solution we are describing are handled assuming a software- centric implementation. It is obvious that when offloaded to hardware acceleration, the load- ing does not exist. Open Radio Access Network (O-RAN) Systems Architecture and Design. DOI: https://doi.org/10.1016/B978-0-323-91923-4.00012-4 © 2022 Elsevier Inc. All rights reserved. Open Radio Access Network (O-RAN) Systems Architecture and Design Packet processing cycle budget analysis The co