Drop the KlogDump helper in favor of klog.InfoS. However, that patch
introduces a new DelayedDumper() helper to avoid processing
(marshalling) of object unless really evaluated by the logging function.
Flatten the data structure that stores features, dropping the "domain"
level from the data model. That extra level of hierarchy brought little
benefit but just caused some extra complexity, instead. The new
structure nicely matches what we have in the NodeFeatureRule object (the
matchFeatures field of uses the same flat structure with the "feature"
field having a value <domain>.<feature>, e.g. "kernel.version").
This is pre-work for introducing a new "node feature" CRD that contains
the raw feature data. It makes the life of both users and developers
easier when both CRDs, plus our internal code, handle feature data in a
similar flat structure.
Move the previously-protobuf-only internal "feature api" over to the
public "nfd api" package. This is in preparation for introducing a new
CRD API for communicating features.
This patch carries no functional changes. Just moving code around.
Refactor the code, moving the hostpath helper functionality to new
"pkg/utils/hostpath" package. This breaks odd-ish dependency
"pkg/utils" -> "source".
Discover "iommu/intel-iommu/version" sysfs attribute for pci devices.
This information is available for custom label rules.
An example custom rule:
- name: "iommu version rule"
labels:
iommu.version_1: "true"
matchFeatures:
- feature: pci.device
matchExpressions:
"iommu/intel-iommu/version": {op: In, value: ["1:0"]}
* fix linter issues for few files
* fix linter issue of exported const Name should have comment or be unexported
* fix name lint issue and resolve lints
* add changes to comments
Add "iommu_group/type" to the list of PCI device attributes that are
discovered. The value is the raw value from sysfs (i.e DMA, DMA-FQ or
identity).
No built-in (automatic) labels are generated based on this, but, the
attribute is available for custom label rules to use. Examples of custom
rules:
- name: "iommu enabled rule"
labels:
iommu.enabled: "true"
matchFeatures:
- feature: pci.device
matchExpressions:
"iommu_group/type": {op: NotIn, value: ["unknown"]}
- name: "iommu passthrough rule"
labels:
iommu.passthrough: "true"
matchFeatures:
- feature: pci.device
matchExpressions:
"iommu_group/type": {op: In, value: ["identity"]}
Separate feature discovery and creation of feature labels in the pci
source.
Move pci_utils from source/internal to the source/pci package. Change
the implementation of the PciID custom rule to utilize the FeatureSource
interface of the pci source.
Also, add minimalist unit test.
Specify a new interface for managing "raw" feature data. This is the
first step to separate raw feature data from node labels. None of the
feature sources implement this interface, yet.
This patch unifies the data format of "raw" features by dividing them
into three different basic types.
- keys, a set of names without any associated values, e.g. CPUID flags
or loaded kernel modules
- values, a map of key-value pairs, for features with a single value,
e.g. kernel config flags or os version
- instances, a list of instances each of which has multiple attributes
(key-value pairs of their own), e.g. PCI or USB devices
The new feature data types are defined in a new "pkg/api/feature"
package, catering decoupling and re-usability of code e.g. within future
extentions of the NFD gRPC API.
Rename the Discover() method of LabelSource interface to GetLabels().
Implement new registration infrastructure under the "source" package.
This change loosens the coupling between label sources and the
nfd-worker, making it easier to refactor and move the code around.
Also, create a separate interface (ConfigurableSource) for configurable
feature sources in order to eliminate boilerplate code.
Add safety checks to the sources that they actually implement the
interfaces they should.
In sake of consistency and predictability (of behavior) change all
methods of the sources to use pointer receivers.
Add simple unit tests for the new functionality and include source/...
into make test target.
Extend the FeatureSource interface with new methods for configuration
handling. This enables easier on-the fly reconfiguration of the
feature sources. Further, it simplifies adding config support to feature
sources in the future. Stub methods are added to sources that do not
currently have any configurability.
The patch fixes some (corner) cases with the overrides (--options)
handling, too:
- Overrides were not applied if config file was missing or its parsing
failed
- Overrides for a certain source did not have effect if an empty config
for the source was specified in the config file. This was caused by
the first pass of parsing (config file) setting a nil pointer to the
source-specific config, effectively detaching it from the main config.
The second pass would then create a new instance of the source
specific config, but, this was not visible in the feature source, of
course.
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>
This will enable code reuse across sources while preventing
packages which are not under 'source' to import it.
subsequent commits will introduce the 'custom' source which
will use the logic.
SR-IOV is a PCI attribute and also non-NIC PCI devices can have it. Therefore,
it is useful to label all PCI devices with that capability.
After this commit the following labels for Intel NICs are overlapping:
feature.node.kubernetes.io/pci-0200_8086.sriov.capable=true
feature.node.kubernetes.io/network-sriov.capable=true
Signed-off-by: Mikko Ylinen <mikko.ylinen@intel.com>
Add new config option for specifying the device label, i.e. the
<device-label> part in
node.alpha.kubernetes-incubator.io/nfd-pci-<device label>.present
The option is a list of field names:
"class" PCI device class
"vendor" Vendor ID
"device" Device ID
"subsystem_vendor" Subsystem vendor ID
"subsystem_device" Subsystem device ID
E.g. the following command line flag can be used to use all of the
above:
--options='{"sources": {"pci": {"deviceLabelFields": ["class", "vendor", "device", "subsystem_vendor", "subsystem_device"] } } }'
User can now configure the list of device classes to detect, either via
a configuration file or by using the --options command line flag.
An example of a command line flag to detect all network controllers and
("main class 0x02) and VGA display controllers ("main" class 0x03 and
subclass 0x00) would be:
--options='{"sources": {"pci": {"deviceClassWhitelist": ["02", "0300"] } } }'
This feature source detects the presence of PCI devices. At the moment,
it only advertises GPUs and accelerator cards, i.e. device classes 0x03,
0x0b40 and 0x12.
The label format is:
node.alpha.kubernetes-incubator.io/nfd-pci-<device label>.present
where <device label> is composed of raw PCI IDs:
<class id>_<vendor id>
