Hyper-threading and CPU Affinity

Hyper-threading can provide increased workload efficiencies in specific configurations, but poorly designed configurations can just as easily impact performance of the OCSBC.

Due to the polling operation of DPDK, using hyper-threaded cores can significantly degrade the OCSBC'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 OSBC has sufficient information to avoid any potential contention from using hyper-threaded sibling cores for realtime critical processes.

In summary:

1. Configurations that have hyperthreading disabled on the host are supported in all cases - same for both bare metal and virtual hosts.
2. Configurations that have hyperthreading enabled on the host are supported if the hypervisor provides correct CPU sibling maps to the guest.
3. 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.

You can verify and troubleshoot the OCSBC CPU assignments using, for example, the show datapath-config command and understanding the following guidelines:

• The OCSBC displays sibling CPUs in lower-case letters:
  • A signaling core with signaling sibling appears as "Ss".
  • There can be no combination of SBC core types, such as "Fd" (Forwarding with DoS).
  • Cores other than signaling appear as the core type with no sibling, such as "Dn".
• The OCSBC displays a verify-config ERROR if there is an error with CPU assignment, including improperly configured hyper-threaded sibling CPUs.