1
0
Fork 0
mirror of https://github.com/kubernetes-sigs/node-feature-discovery.git synced 2025-03-19 23:03:13 +00:00
node-feature-discovery/deployment/components/worker-config/nfd-worker.conf.example

187 lines
5.2 KiB
Text
Raw Normal View History

#core:
# labelWhiteList:
# noPublish: false
# sleepInterval: 60s
# sources: [all]
# klog:
# addDirHeader: false
# alsologtostderr: false
# logBacktraceAt:
# logtostderr: true
# skipHeaders: false
# stderrthreshold: 2
# v: 0
# vmodule:
## NOTE: the following options are not dynamically run-time configurable
## and require a nfd-worker restart to take effect after being changed
# logDir:
# logFile:
# logFileMaxSize: 1800
# skipLogHeaders: false
#sources:
# cpu:
# cpuid:
## NOTE: whitelist has priority over blacklist
# attributeBlacklist:
# - "BMI1"
# - "BMI2"
# - "CLMUL"
# - "CMOV"
# - "CX16"
# - "ERMS"
# - "F16C"
# - "HTT"
# - "LZCNT"
# - "MMX"
# - "MMXEXT"
# - "NX"
# - "POPCNT"
# - "RDRAND"
# - "RDSEED"
# - "RDTSCP"
# - "SGX"
# - "SSE"
# - "SSE2"
# - "SSE3"
# - "SSE4"
# - "SSE42"
# - "SSSE3"
# attributeWhitelist:
# kernel:
# kconfigFile: "/path/to/kconfig"
# configOpts:
# - "NO_HZ"
# - "X86"
# - "DMI"
# pci:
# deviceClassWhitelist:
# - "0200"
# - "03"
# - "12"
# deviceLabelFields:
# - "class"
# - "vendor"
# - "device"
# - "subsystem_vendor"
# - "subsystem_device"
usb: Add support for USB device discovery This builds on the PCI support to enable the discovery of USB devices. This is primarily intended to be used for the discovery of Edge-based heterogeneous accelerators that are connected via USB, such as the Coral USB Accelerator and the Intel NCS2 - our main motivation for adding this capability to NFD, and as part of our work in the SODALITE H2020 project. USB devices may define their base class at either the device or interface levels. In the case where no device class is set, the per-device interfaces are enumerated instead. USB devices may furthermore have multiple interfaces, which may or may not use the identical class across each interface. We therefore report device existence for each unique class definition to enable more fine-grained labelling and node selection. The default labelling format includes the class, vendor and device (product) IDs, as follows: feature.node.kubernetes.io/usb-fe_1a6e_089a.present=true As with PCI, a subset of device classes are whitelisted for matching. By default, there are only a subset of device classes under which accelerators tend to be mapped, which is used as the basis for the whitelist. These are: - Video - Miscellaneous - Application Specific - Vendor Specific For those interested in matching other classes, this may be extended by using the UsbId rule provided through the custom source. A full list of class codes is provided by the USB-IF at: https://www.usb.org/defined-class-codes For the moment, owing to a lack of a demonstrable use case, neither the subclass nor the protocol information are exposed. If this becomes necessary, support for these attributes can be trivially added. Signed-off-by: Paul Mundt <paul.mundt@adaptant.io>
2020-05-14 22:32:55 +02:00
# usb:
# deviceClassWhitelist:
# - "0e"
# - "ef"
# - "fe"
# - "ff"
# deviceLabelFields:
# - "class"
# - "vendor"
# - "device"
# custom:
# - name: "my.kernel.feature"
# matchOn:
# - loadedKMod: ["example_kmod1", "example_kmod2"]
# - name: "my.pci.feature"
# matchOn:
# - pciId:
# class: ["0200"]
# vendor: ["15b3"]
# device: ["1014", "1017"]
# - pciId:
# vendor: ["8086"]
# device: ["1000", "1100"]
usb: Add support for USB device discovery This builds on the PCI support to enable the discovery of USB devices. This is primarily intended to be used for the discovery of Edge-based heterogeneous accelerators that are connected via USB, such as the Coral USB Accelerator and the Intel NCS2 - our main motivation for adding this capability to NFD, and as part of our work in the SODALITE H2020 project. USB devices may define their base class at either the device or interface levels. In the case where no device class is set, the per-device interfaces are enumerated instead. USB devices may furthermore have multiple interfaces, which may or may not use the identical class across each interface. We therefore report device existence for each unique class definition to enable more fine-grained labelling and node selection. The default labelling format includes the class, vendor and device (product) IDs, as follows: feature.node.kubernetes.io/usb-fe_1a6e_089a.present=true As with PCI, a subset of device classes are whitelisted for matching. By default, there are only a subset of device classes under which accelerators tend to be mapped, which is used as the basis for the whitelist. These are: - Video - Miscellaneous - Application Specific - Vendor Specific For those interested in matching other classes, this may be extended by using the UsbId rule provided through the custom source. A full list of class codes is provided by the USB-IF at: https://www.usb.org/defined-class-codes For the moment, owing to a lack of a demonstrable use case, neither the subclass nor the protocol information are exposed. If this becomes necessary, support for these attributes can be trivially added. Signed-off-by: Paul Mundt <paul.mundt@adaptant.io>
2020-05-14 22:32:55 +02:00
# - name: "my.usb.feature"
# matchOn:
# - usbId:
# class: ["ff"]
# vendor: ["03e7"]
# device: ["2485"]
usb: Add support for USB device discovery This builds on the PCI support to enable the discovery of USB devices. This is primarily intended to be used for the discovery of Edge-based heterogeneous accelerators that are connected via USB, such as the Coral USB Accelerator and the Intel NCS2 - our main motivation for adding this capability to NFD, and as part of our work in the SODALITE H2020 project. USB devices may define their base class at either the device or interface levels. In the case where no device class is set, the per-device interfaces are enumerated instead. USB devices may furthermore have multiple interfaces, which may or may not use the identical class across each interface. We therefore report device existence for each unique class definition to enable more fine-grained labelling and node selection. The default labelling format includes the class, vendor and device (product) IDs, as follows: feature.node.kubernetes.io/usb-fe_1a6e_089a.present=true As with PCI, a subset of device classes are whitelisted for matching. By default, there are only a subset of device classes under which accelerators tend to be mapped, which is used as the basis for the whitelist. These are: - Video - Miscellaneous - Application Specific - Vendor Specific For those interested in matching other classes, this may be extended by using the UsbId rule provided through the custom source. A full list of class codes is provided by the USB-IF at: https://www.usb.org/defined-class-codes For the moment, owing to a lack of a demonstrable use case, neither the subclass nor the protocol information are exposed. If this becomes necessary, support for these attributes can be trivially added. Signed-off-by: Paul Mundt <paul.mundt@adaptant.io>
2020-05-14 22:32:55 +02:00
# - usbId:
# class: ["fe"]
# vendor: ["1a6e"]
# device: ["089a"]
# - name: "my.combined.feature"
# matchOn:
# - pciId:
# vendor: ["15b3"]
# device: ["1014", "1017"]
# loadedKMod: ["vendor_kmod1", "vendor_kmod2"]
# - name: "feature.by.nodename"
# value: customValue
# matchOn:
# - nodename: ["worker-0", "my-.*-node"]
source/custom: implement generic feature matching Implement generic feature matchers that cover all feature sources (that implement the FeatureSource interface). The implementation relies on the unified data model provided by the FeatureSource interface as well as the generic expression-based rule processing framework that was added to the source/custom/expression package. With this patch any new features added will be automatically available for custom rules, without any additional work. Rule hierarchy follows the source/feature hierarchy by design. This patch introduces a new format for custom rule specifications, dropping the 'value' field and introducing new 'labels' field which makes it possible to specify multiple labels per rule. Also, in the new format the 'name' field is just for reference and no matching label is created. The new generic rules are available in this new rule format under a 'matchFeatures. MatchFeatures implements a logical AND over an array of per-feature matchers - i.e. a match for all of the matchers is required. The goal of the new rule format is to make it better follow K8s API design guidelines and make it extensible for future enhancements (e.g. addition of templating, taints, annotations, extended resources etc). The old rule format (with cpuID, kConfig, loadedKMod, nodename, pciID, usbID rules) is still supported. The rule format (new vs. old) is determined at config parsing time based on the existence of the 'matchOn' field. The new rule format and the configuration format for the new matchFeatures field is - name: <rule-name> labels: <key>: <value> ... matchFeatures: - feature: <domain>.<feature> matchExpressions: <attribute>: op: <operator> value: - <list-of-values> - feature: <domain>.<feature> ... Currently, "cpu", "kernel", "pci", "system", "usb" and "local" sources are covered by the matshers/feature selectors. Thus, the following features are available for matching with this patch: - cpu.cpuid: <cpuid-flag>: <exists/does-not-exist> - cpu.cstate: enabled: <bool> - cpu.pstate: status: <string> turbo: <bool> scaling_governor: <string> - cpu.rdt: <rdt-feature>: <exists/does-not-exist> - cpu.sst: bf.enabled: <bool> - cpu.topology: hardware_multithreading: <bool> - kernel.config: <flag-name>: <string> - kernel.loadedmodule: <module-name>: <exists/does-not-exist> - kernel.selinux: enabled: <bool> - kernel.version: major: <int> minor: <int> revision: <int> full: <string> - system.osrelease: <key-name>: <string> VERSION_ID.major: <int> VERSION_ID.minor: <int> - system.name: nodename: <string> - pci.device: <device-instance>: class: <string> vendor: <string> device: <string> subsystem_vendor: <string> susbystem_device: <string> sriov_totalvfs: <int> - usb.device: <device-instance>: class: <string> vendor: <string> device: <string> serial: <string> - local.label: <label-name>: <string> The configuration also supports some "shortforms" for convenience: matchExpressions: [<attr-1>, <attr-2>=<val-2>] --- matchExpressions: <attr-3>: <attr-4>: <val-4> is equal to: matchExpressions: <attr-1>: {op: Exists} <attr-2>: {op: In, value: [<val-2>]} --- matchExpressions: <attr-3>: {op: Exists} <attr-4>: {op: In, value: [<val-4>]} In other words: - feature: kernel.config matchExpressions: ["X86", "INIT_ENV_ARG_LIMIT=32"] - feature: pci.device matchExpressions: vendor: "8086" is the same as: - feature: kernel.config matchExpressions: X86: {op: Exists} INIT_ENV_ARG_LIMIT: {op: In, values: ["32"]} - feature: pci.device matchExpressions: vendor: {op: In, value: ["8086"] Some configuration examples below. In order to match a CPUID feature the following snippet can be used: - name: cpu-test-1 labels: cpu-custom-feature: "true" matchFeatures: - feature: cpu.cpuid matchExpressions: AESNI: {op: Exists} AVX: {op: Exists} In order to match against a loaded kernel module and OS version: - name: kernel-test-1 labels: kernel-custom-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: e1000: {op: Exists} - feature: system.osrelease matchExpressions: NAME: {op: InRegexp, values: ["^openSUSE"]} VERSION_ID.major: {op: Gt, values: ["14"]} In order to require a kernel module and both of two specific PCI devices: - name: multi-device-test labels: multi-device-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: driver-module: {op: Exists} - pci.device: vendor: "8086" device: "1234" - pci.device: vendor: "8086" device: "abcd"
2021-10-14 10:22:07 +03:00
#
# # The following feature demonstrates the capabilities of the matchFeatures
# - name: "my.ng.feature"
# labels:
# my-ng-feature: "true"
# # matchFeatures implements a logical AND over all matcher terms in the
# # list (i.e. all of the terms, or per-feature matchers, must match)
# matchFeatures:
# - feature: cpu.cpuid
# matchExpressions:
# AVX512F: {op: Exists}
# - feature: cpu.cstate
# matchExpressions:
# enabled: {op: IsTrue}
# - feature: cpu.pstate
# matchExpressions:
# no_turbo: {op: IsFalse}
# scaling_governor: {op: In, value: ["performance"]}
# - feature: cpu.rdt
# matchExpressions:
# RDTL3CA: {op: Exists}
# - feature: cpu.sst
# matchExpressions:
# bf.enabled: {op: IsTrue}
# - feature: cpu.topology
# matchExpressions:
# hardware_multithreading: {op: IsFalse}
#
# - feature: kernel.config
# matchExpressions:
# X86: {op: Exists}
# LSM: {op: InRegexp, value: ["apparmor"]}
# - feature: kernel.loadedmodule
# matchExpressions:
# e1000e: {op: Exists}
# - feature: kernel.selinux
# matchExpressions:
# enabled: {op: IsFalse}
# - feature: kernel.version
# matchExpressions:
# major: {op: In, value: ["5"]}
# minor: {op: Gt, value: ["10"]}
#
# - feature: system.osrelease
# matchExpressions:
# ID: {op: In, value: ["fedora", "centos"]}
# - feature: system.name
# matchExpressions:
# nodename: {op: InRegexp, value: ["^worker-X"]}
#
# - feature: local.label
# matchExpressions:
# custom-feature-knob: {op: Gt, value: ["100"]}
#
# # The following feature demonstrates the capabilities of the matchAny
# - name: "my.ng.feature.2"
# labels:
# my-ng-feature-2: "my-value"
# # matchAny implements a logical IF over all elements (sub-matchers) in
# # the list (i.e. at least one feature matcher must match)
# matchAny:
# - matchFeatures:
# - feature: kernel.loadedmodule
# matchExpressions:
# driver-module-X: {op: Exists}
# - feature: pci.device
# matchExpressions:
# vendor: {op: In, value: ["8086"]}
# class: {op: In, value: ["0200"]}
# - matchFeatures:
# - feature: kernel.loadedmodule
# matchExpressions:
# driver-module-Y: {op: Exists}
# - feature: usb.device
# matchExpressions:
# vendor: {op: In, value: ["8086"]}
# class: {op: In, value: ["02"]}