NVIDIA Data Center GPU Manager (DCGM)

repository·master·Indexed 20 days ago

https://github.com/nvidia/dcgm

A suite of tools for monitoring, managing, and diagnosing NVIDIA datacenter GPUs in cluster environments. Supports Linux on x86_64, Arm, and POWER architectures. Features include active health monitoring, diagnostics, system alerts, governance policies, and Kubernetes support via dcgm-exporter. The repository includes a Docker-based build environment (dcgmbuild) and an NVML Injection framework for mocking NVML API return values during testing.

Tokens
16K
Snippets
39
Records
70
Agent score
73%

What's inside DCGM

  1. Overview of the dcgmbuild environment

    master
    The dcgmbuild repository provides a Docker-based build environment designed to facilitate the compilation of DCGM components. It includes the necessary infrastructure for cross-compilation (e.g., for x86_64 and aarch64) and manages the dependencies required for both the build host and the target architectures.
  2. What is NVIDIA Data Center GPU Manager (DCGM)?

    master

    NVIDIA Data Center GPU Manager (DCGM) is a suite of tools designed for managing and monitoring NVIDIA datacenter GPUs in cluster environments. It provides:

    • Active health monitoring and comprehensive diagnostics.
    • System alerts and governance policies (including power and clock management).
    • Integration capabilities for cluster management tools, resource scheduling, and monitoring products.
    • Kubernetes support via dcgm-exporter for gathering GPU telemetry.

    DCGM supports Linux operating systems on x86_64, Arm, and POWER (ppc64le) platforms. The installer packages include libraries, binaries, NVIDIA Validation Suite (NVVS), and API source examples for C, Python, and Go.

  3. Use the NSCQ Dynamic Library Wrapper (dlwrap)

    master

    The dlwrap library provides thread-safe wrappers for locating, loading, and mapping symbols from the NSCQ shared library using OS-specific APIs (such as dlopen()).

    Most dlwrap APIs are direct pass-throughs to the underlying NSCQ library APIs, maintaining identical names and argument lists. To manage the lifecycle of the loaded library, you must use the nscq_dlwrap_attach and nscq_dlwrap_detach functions.

  4. Understand the DCGM product lifecycle and release model

    master

    DCGM follows Semantic Versioning (SemVer) in the format X.Y.z. The release cycle is tied to the driver LLB lifecycle, with major or minor revisions (X or Y) occurring approximately twice a year.

    Release Types:

    • Current Release: The primary branch for new features and patch releases. This is the recommended version for most users.
    • Maintenance Release: A supported version that is eligible for patch releases. However, if a fix is available in the Current Release, users are encouraged to upgrade to that instead of waiting for a maintenance patch.
    • Legacy Releases: Versions that have passed their one-year support window. No patch releases are created for legacy releases. Bugs reported in legacy versions will be addressed in the Current or Maintenance releases instead.

    Versioning Rules:

    • Major (X): Breaking API changes (often occurring at architecture boundaries).
    • Minor (Y): New API additions.
    • Patch (z): Bug fixes (released quarterly).
  5. Error handling and exception usage in DCGM

    master

    Exceptions are prohibited in DCGM code and will result in code review rejection. Instead of using throw, follow these patterns:

    1. Use Return Codes: Communicate error conditions through return codes and the error log.
    2. Initialization Methods: For code that might fail during setup, use an Initialize() method that returns an error status.
    3. Third-party Exceptions: If using third-party libraries that throw exceptions, catch them at the source and convert them into DCGM-style error reporting (return codes).
  6. Mock NVML APIs using NVML Injection

    master

    NVML Injection allows you to mock the return values of NVML calls for testing purposes. There are two ways to provide mocked values:

    1. YAML Configuration: Loading values from an NVML injection YAML file (e.g., via run_with_injection_nvml_using_specific_sku).
    2. Manual Injection: Using the dcgmInjectNvmlDevice API.

    Priority Rule: Manual injection via dcgmInjectNvmlDevice has higher priority than values loaded from a YAML file. If both are present, the manually injected value is used.

    Key Implementation Rules

    • Target Naming: When specifying the injection target, do not include the Get prefix. For example, to mock nvmlDeviceGetFanSpeed, use the target name FanSpeed. This allows the same injection to affect both getters and setters (e.g., nvmlDeviceSetFanSpeed).
    • Device Handles: Since the Python injection code cannot directly provide a device handle, pass the gpuId. The dcgmInjectNvmlDevice function will automatically translate the gpuId into the appropriate device handle.
    • Overriding: Calling dcgmInjectNvmlDevice multiple times on the same API will override previous values. To test multiple fields, perform individual injections.
    # Example of mocking nvmlDeviceGetNvLinkErrorCounter
    def mock_nvlink_error_counter(handle, gpuId, linkId, counterType, nvmlRet, value):
        # 1. Define the return value (injectedRet)
        injectedRet = nvml_injection.c_injectNvmlRet_t()
        injectedRet.nvmlRet = nvmlRet
        injectedRet.values[0].type = nvml_injection_structs.c_injectionArgType_t.INJECTION_ULONG_LONG
        injectedRet.values[0].value.ULongLong = value
        injectedRet.valueCount = 1
    
        # 2. Define extra keys (parameters) for the function
        extraKeysType = nvml_injection_structs.c_injectNvmlVal_t * 2
        extraKeys = extraKeysType()
        extraKeys[0].type = nvml_injection_structs.c_injectionArgType_t.INJECTION_UINT
        extraKeys[0].value.UInt = linkId
        extraKeys[1].type = nvml_injection_structs.c_injectionArgType_t.INJECTION_NVLINKERRORCOUNTER
        extraKeys[1].value.NvLinkErrorCounter = counterType
    
        # 3. Execute injection
        ret = dcgm_agent_internal.dcgmInjectNvmlDevice(handle, gpuId, "NvLinkErrorCounter", extraKeys, 2, injectedRet)
        assert (ret == dcgm_structs.DCGM_ST_OK)
  7. Understand the NVML Injection YAML format

    master

    The YAML file maps NVML function calls to specific return values using a key-based system.

    Keys and Extra Keys

    • Key: The key is the suffix of the NVML function name. For example, nvmlDeviceGetTotalEccErrors uses the key TotalEccErrors. This allows setters and getters (e.g., nvmlDeviceGetFanSpeed and nvmlDeviceSetFanSpeed) to share the same state.
    • Extra Keys: For functions with multiple inputs, InjectionArgument (a union of NVML structures and basic types) is used. For example, a function with a fan parameter might use INJECTION_UINT as an extra key.

    YAML Structure Example

    Each entry maps a key (and optional extra keys) to a FunctionReturn (nvmlReturn_t) and a ReturnValue.

    APIRestriction:
      0:
        FunctionReturn: 3
      1:
        FunctionReturn: 0
        ReturnValue: 0

    In this example, APIRestriction is the primary key, and 0 and 1 are extra keys representing different input arguments.

  8. How DCGM is architected

    master

    DCGM uses a modular design to monitor NVIDIA GPU health and telemetry. The core architecture consists of:

    • APIs: Interfaces for interacting with the DCGM agent (nv-hostengine).
    • Telemetry Cache: Stores known telemetry data.
    • Functional Modules:
      • Health: Passive monitoring of fields indicating workload readiness.
      • Configuration: Tools for configuring GPUs for usage.
      • Policy alerting: Automatic reactions to specific GPU conditions.
      • Job / process stats: Monitoring how processes utilize GPUs.
      • Diagnostics: Active stress tests for GPUs and related components.
      • NVSwitch: Interaction with system NVSwitches.
      • Profiling: (Closed source) Provides GPU usage profiling information.
  9. Understand the dcgmbuild directory structure

    master

    The dcgmbuild environment is organized into several functional directories:

    • dockerfiles: Contains Dockerfiles used to generate the container images for the build environment.
    • cmake: Contains toolchain files required for cross-compiling source code.
    • crosstool-ng: Contains configuration files for crosstool-ng, which is used to generate cross-compilers and toolsets for x86_64 and aarch64 architectures.
    • scripts/host: Contains scripts for building libraries and tools required by the build host.
    • scripts/target: Contains scripts for building 3rd party libraries for target architectures using cross-compilers.
  10. Run the DCGM Test Framework

    master

    DCGM includes an extensive test suite that can be run on any system with one or more supported GPUs. The test suite utilizes DCGM's Python bindings.

    To run the tests:

    1. Build the DCGM tarballs (this creates a datacenter-gpu-manager-tests package alongside the standard package).
    2. Extract the datacenter-gpu-manager-tests tarball.
    3. Navigate to the share/dcgm_tests directory.
    4. Execute the test script with root privileges:
    sudo run_tests.sh

    Note: The test suite typically takes between 10 and 60 minutes to complete, depending on the hardware (number of GPUs, NVSwitches, NVLinks, etc.).

    # After extracting the tests package
    cd share/dcgm_tests
    sudo run_tests.sh
  11. Process for adding new functions to NVML Injection

    master

    To enable injection for a new NVML function, follow these steps:

    1. Define the function: Add the new functions and definitions to dcgm_nvml.h and entry_points.h.
    2. Generate stubs: Run generate_nvml_stubs.py from the dcgm/ root to update the fake implementations.
    3. Update the recorder: Update nvml_api_recorder.py so it can capture values from the new function. This involves:
      • Adding the function to _nvml_device_attr_funcs (for simple functions) or _nvml_device_extra_key_attr_funcs (for functions with multiple inputs).
      • Writing a YAML serializer (e.g., pci_info_parser) to convert the C++ structure into a dictionary. Note: Use C++ field names as the serialized keys in the YAML.
      • For functions using references for output (e.g., nvmlDeviceGetGpuFabricInfo), write a wrapper function in nvml_api_recorder.py to handle the output parameter.
    4. Update YAML: Add the new key to your test YAML files or modify the YAML directly to simulate specific return values.
    5. Test: Run your program with NVML_INJECTION_MODE=True and NVML_YAML_FILE=<path>.