feat(input.intel_pmt): Add pci_bdf tag to uniquely identify GPUs and other peripherals

[bensallen]

In the current intel_pmt plugin, the numa_node of the intel_pmt device is used as a way to uniquely identify which CPU socket the sample belongs to. However, with GPUs and other future peripherals, an additional tag is needed to uniquely identify samples.

Thus add the parent of intel_pmt's device PCI Bus:Device.Function (BDF) as the tag pci_bdf. We find the PCI BDF by traversing up from telemDeviceSymlink and taking it's basename. Equivalent example in bash:

$ basename $(realpath /sys/class/intel_pmt/telem10/device/..)
0000:e7:03.1

All intel_pmt parent devices appear to be PCI devices, so we shouldn't need to special-case this tag between CPUs and other peripherals.

Sample including pci_bdf:

> intel_pmt,datatype_idref=ttemperature,guid=0x9956f43f,host=node001,numa_node=0,pci_bdf=0000:e7:03.1,sample_group=TEMPERATURE[4],sample_name=CORE_TEMP value=36.4140625 1695671600000000000

Required for all PRs

• Updated associated README.md.
• Wrote appropriate unit tests.
• Pull request title or commits are in conventional commit format

resolves #14003

[telegraf-tiger]

Download PR build artifacts for linux_amd64.tar.gz, darwin_amd64.tar.gz, and windows_amd64.zip.
Downloads for additional architectures and packages are available below.

⚠️ This pull request increases the Telegraf binary size by 2.19 % for linux amd64 (new size: 202.0 MB, nightly size 197.7 MB)

📦 Click here to get additional PR build artifacts

Artifact URLs

DEB	RPM	TAR GZ	ZIP
amd64.deb	aarch64.rpm	darwin_amd64.tar.gz	windows_amd64.zip
arm64.deb	armel.rpm	darwin_arm64.tar.gz	windows_arm64.zip
armel.deb	armv6hl.rpm	freebsd_amd64.tar.gz	windows_i386.zip
armhf.deb	i386.rpm	freebsd_armv7.tar.gz
i386.deb	ppc64le.rpm	freebsd_i386.tar.gz
mips.deb	riscv64.rpm	linux_amd64.tar.gz
mipsel.deb	s390x.rpm	linux_arm64.tar.gz
ppc64el.deb	x86_64.rpm	linux_armel.tar.gz
riscv64.deb		linux_armhf.tar.gz
s390x.deb		linux_i386.tar.gz
		linux_mips.tar.gz
		linux_mipsel.tar.gz
		linux_ppc64le.tar.gz
		linux_riscv64.tar.gz
		linux_s390x.tar.gz

[powersj]

Thanks again for another issue + PR, I'll ask @p-zak and the other intel folks for a review as well, but two questions:

However, with GPUs and other future peripherals, an additional tag is needed to uniquely identify samples.

Is there an example we can add as a test that includes a non-CPU device?

Is the PCI Bus:Device.Function coarse enough for future devices as well?

[bensallen]

Is there an example we can add as a test that includes a non-CPU device?

There doesn't appear to be anything that is unique about PMT devices for non-CPUs compared to CPUs, other than different GUIDs and thus referencing other XML entries. Generally this is the whole idea behind Intel PMT, providing a common interface to telemetry. The Intel folks might have better idea if there's addition test cases that'd provide better coverage.

Is the PCI Bus:Device.Function coarse enough for future devices as well?

I believe so yes. I've also not found other discoverable attributes about a intel_pmt or intel_vsec device that we could use as a tag to help uniquely identify components.

[bensallen]

Tagging @jakubsikorski for review as well in-case he hasn't seen this. Thanks Kuba!

[jakubsikorski]

Is there an example we can add as a test that includes a non-CPU device?

There doesn't appear to be anything that is unique about PMT devices for non-CPUs compared to CPUs, other than different GUIDs and thus referencing other XML entries. Generally this is the whole idea behind Intel PMT, providing a common interface to telemetry. The Intel folks might have better idea if there's addition test cases that'd provide better coverage.

There is no difference whether the device is a CPU or not. Intel PMT telemetry will be visible for that device as a PCI device that has a BDF. Different devices - whether it's 2 CPUs in a 2 socket server or 2 GPUs - will have different PCI BDFs. The only difference between devices will be the amount of intel_pmt telemetry they can expose, but that is a difference on the GUID and XML spec level (and the plugin reads all that it can).

Is the PCI Bus:Device.Function coarse enough for future devices as well?

I believe so yes. I've also not found other discoverable attributes about a intel_pmt or intel_vsec device that we could use as a tag to help uniquely identify components.

Yes, this should be enough. We will now have guid identifying unique intel pmt telemetry semantic space, numa_node to identify the socket and pci_bdf to identify the device exposing the telemetry.

[p-zak]

LGTM!

@bensallen Thanks for PR!

[srebhan]

Thanks @bensallen for your contribution!