Developer Documentation on DRA Driver for CPU

Testing

Mon, 01 Jan 0001 00:00:00 +0000

Running the tests

Unit Tests

To run the node-local unit tests, run:

make test-unit

Chart render tests

To check what the Helm chart renders, without a cluster, run:

make helm-render-check

hack/ci/helm-render-check.sh renders each case and hands the DaemonSet to the validator in test/render. It needs Helm and the project’s Go toolchain, but no cluster. The cluster-side counterpart is the helm e2e workflow, which installs the chart against both the default and a relocated kubelet root.

Linting

Mon, 01 Jan 0001 00:00:00 +0000

Run the linter against the codebase:

make lint

To automatically fix lint issues, pass --fix via the GOLANGCI_LINT_EXTRA_ARGS variable:

GOLANGCI_LINT_EXTRA_ARGS=--fix make lint

GOLANGCI_LINT_EXTRA_ARGS is forwarded verbatim to golangci-lint run, so any other supported flags can be passed the same way.

Logging Guidelines

Mon, 01 Jan 0001 00:00:00 +0000

picking a verbosity level

V(0): high-signal operational logs and errors always visible at default verbosity V(2): normal operation, important decisions, summary, container lifecycle V(4): allocation internals, fine details about decisions V(6): debug messages, very fine details, mostly for developers

V(7) or more is reserved for future usage.

when to use Error()

Summary: use Error() if we need to log an unrecoverable error which leads to a failed state, not to a degraded-but-operational state.

Configuration Guidelines

Mon, 01 Jan 0001 00:00:00 +0000

The configurable behavior of the DRA CPU driver can be changed using two approaches:

command line flags
configuration file

The preferred way to add or extend the configurable behavior is through the configuration file. The reasons why we prefer this approach are:

user friendliness: adding options quickly makes the command line long and awkward
auditable, reviewable artifact: the configuration file can be versioned, compared and verified more easily
extensibility: it’s usually easier to process configuration files with programs than command line options
configuration files are easier to version and evolve compatibly than command line flags.

Configuration values are applied incrementally:

Deep Dive: Cgroup v2, QoS Classes, and CPU Enforcement in Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

This document provides a technical deep-dive into how Kubernetes organizes Linux control groups under cgroup v2, calculates and applies Quality of Service (QoS) classes, manages cgroup hierarchies at node, QoS, pod, and container levels, and enforces CPU allocations. It also documents the architectural relationship between Kubelet’s cgroup management and out-of-tree Dynamic Resource Allocation (DRA) drivers such as dra-driver-cpu.

1. The Linux Cgroup v2 Hierarchy in Kubernetes

Under cgroup v2 with the systemd cgroup driver, Kubernetes organizes container processes into a strictly hierarchical tree under /sys/fs/cgroup/kubepods.slice:

Deep dive: how linux reports topology attributes

Mon, 01 Jan 0001 00:00:00 +0000

disclosure: this document was created with AI assistance. The research was human-steered by LLM-operated; the document was then reviewed by humans for correctness and edited extensively.

This document assumes kernel code, architecture and hardware management knowledge.

This document tries to be architecture agnostic whenever possible, but the author can only claim sufficient knowledge about the x86_64 architecture. The reader must assume the “silicon” and hardware is assumed to be x86_64 unless clearly specified otherwise.

Deep dive: finding and exploring PCI/PCIe root buses

Mon, 01 Jan 0001 00:00:00 +0000

disclosure: this document was created with AI assistance. The research was human-steered by LLM-operated; the document was then reviewed by humans for correctness and edited extensively.

This document assumes kernel code, architecture and hardware management knowledge.

SMT layout encoding

Mon, 01 Jan 0001 00:00:00 +0000

dra.cpu/smtLayout is a compact representation of logical-CPU sibling pairs.

We reserve the option to version the encoding, adding new versions with the Vxxx suffix appended. The reason for this decision is because, albeit aiming to be correct and completed, the encoding format didn’t get sufficient testing and validation to be called confidently final. Therefore we version to enable smooth future upgrades. Users should consider then unversioned name dra.cpu/smtLayout effectively as synonym for V1. The V1 format represents only two-way SMT; see the user-facing attribute reference for more details.