Hyperthreading and CPU Affinity
Hyperthreading can provide increased workload efficiencies in specific configurations, but poorly designed configurations can just as easily impact performance of the SBC.
Due to the polling operation of DPDK, using hyper-threaded cores can significantly degrade the SBC's packet processing performance. Oracle recommends you disable hyper-threading on the host system if possible, or configure CPU affinities on the hypervisor to ensure mapping from only one virtual CPU to each physical CPU core. Learn how to configure CPU affinity via your hypervisor documentation.
To use hyper-threading with OCSBC, it's important that the hypervisor passes a valid CPU map to the VM, so that SBC has sufficient information to avoid any potential contention from using hyper-threaded sibling cores for realtime critical processes.
- Configurations that have hyperthreading disabled on the host are supported in all cases - same for both bare metal and virtual hosts.
- Configurations that have hyperthreading enabled on the host are supported if the hypervisor provides correct CPU sibling maps to the guest. This also requires that you enable the use-sibling-core-datapath parameter.
- Configurations that have hyperthreading enabled on the host but do not report sibling maps to the guest are unsupported unless CPU cores are manually pinned at the hypervisor to avoid sibling contention. This also requires that you enable the use-sibling-core-datapath parameter.
You can verify and troubleshoot the SBC CPU assignments using, for example, the show datapath-config command and understanding the following guidelines:
- The SBC
displays sibling CPUs in lower-case letters:
- A signaling core with signaling sibling appears as "Ss".
- Cores other than signaling appear as the core type with no sibling, such as "Dn".
- The SBC displays a verify-config ERROR if there is an error with CPU assignment, including improperly configured hyper-threaded sibling CPUs.