On Wed, Apr 13, 2022 at 2:13 PM Thomas Monjalon <tho...@monjalon.net> wrote: > > > Let me explain in more detail. > > > > > > This patch actually include two parts: > > > 1. Module EEPROM raw data parser code > > > Files: sff_common.h, sff_common.c, sff_8xxx.* > > > 2. Add new telemetry command > > > Files: sff_telemetry.h, sff_telemetry.c > > > > > > Part 1 will only parsing the module EEPROM raw data base on different > > > module type. > > > Now DPDK support 4 types that defined in rte_dev_info.h with macro > > > RTE_ETH_MODULE_SFF_8xxx. > > > > > > Part 2 will call rte_eth_dev_get_module_info and > > > rte_eth_dev_get_module_eeprom to get the module EEPROM raw data, then > > > pass the raw data to Part 1 parser code. Finally, Part 1 parser code will > > > print formatted information. > > > > > > So, these codes are more likely a common tool than a common driver, > > > because it will only read the module EEPROM raw data from NIC PMD driver. > > > For those NIC drivers who has not implemented get_module_info and > > > get_module_eeprom dev_ops, we will simply return not support. > > > > > Thanks for the additional explanation. Adding more folks on CC who may have > > more thoughts on the best way to handle this. > > That's ethdev and/or net driver code. > If I understand well, SFF are standards and no tight to any HW, right?
That's my understanding too. > In this case, I think the common code can be in ethdev library. +1 -- David Marchand
