[Feature] qsfpinfo: New tool to print QSFP EEPROM information

[rchriste1]

[Feature]- qsfpinfo: New tool to print QSFP EEPROM information for modules in cards with qsfp feature (id 0x13).

Layout is imported from ethertool repo.
Imported c-files are wrapped to undefine HAVE_CONFIG_H to avoid importing more files.

------------- Keep everything below this line -------------------------

Description

Describe the issue, update, change or fix and why

Collateral (docs, reports, design examples, case IDs):

• Document Update Required? (Specify FIM/AFU/Scripts)

Tests added:

Tests run:

[coveralls]

Pull Request Test Coverage Report for Build 8851240764

Details

• 0 of 164 (0.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.4%) to 64.22%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
binaries/qsfpinfo/main.c	0	164	0.0%

Totals
Change from base Build 8818231667:	-0.4%
Covered Lines:	15825
Relevant Lines:	24642

---

💛 - Coveralls

[pcolberg]

This will fail in a build sandbox without network access, e.g., when building for Fedora or Yocto. Is there any way to obtain the required functionality from a library?

[rchriste1]

The code used is normally compiled into the ethertool binary. The qsfpinfo program calls a static function internally in the code. So there is no library providing that interface. Since the dfl drivers do not create a Linux network interface we cannot use ethertool directly.

ExternalProject_Add() is also used in other places in opae-sdk.

[pcolberg]

The code used is normally compiled into the ethertool binary. The qsfpinfo program calls a static function internally in the code. So there is no library providing that interface. Since the dfl drivers do not create a Linux network interface we cannot use ethertool directly.

Do you know why the DFL drivers do not create a Linux netlink interface that could be consumed by regular ethtool or libnl? Are there any fundamental blockers to implementing this or has it simply not been considered necessary so far?

ExternalProject_Add() is also used in other places in opae-sdk.

Please correct me if I am wrong, but OPAE SDK does not have any mandatory external dependencies.

opae-sdk$ rg ExternalProject_Add
CMakeLists.txt
110:    ExternalProject_Add(uuid
378:        ExternalProject_Add(libedit
492:        ExternalProject_Add(hwloc
598:        ExternalProject_Add(numa

Those are libraries provided by the distribution, hence are not needed to build in an isolated sandbox. In the worst case, the qsfpinfo tool could be disabled by default, but I am wondering if there is a better solution that allows using rather than forking ethtool.

[rchriste1]

@matthew-gerlach may no more about why the drivers do not implement "a Linux netlink interface". The qsfp-mem driver only implements QSFP handling. I know that the HSSI could not be accepted by Linux community as a network interface because you cannot send and receive packets. So HSSI is handled in user space.

[fpgamatt]

To be a valid, accepted "Linux netlink interface", the device must transmit and receive packets between the network connection and memory. The HSSI and QSFP subsystems are just pieces of the pipeline of full netlink device.

[rchriste1]

I have made the printing of QSFP information, thus importing from Ethertool, dependent on cmake option OPAE_WITH_QSFPINFO_QSFPPRINT, which is OFF by default. qsfpinfo will thus by default only print if the QSFP modules are present or not. In this way the qsfpinfo binary is always part of the packages built.