On Fri, 9 Oct 2026, Thomas Monjalon wrote: > This is specific to networking devices, right? > So it has to be linked with ethdev probably. > But if it is not specific to any driver, > we may consider moving it to separate library. > I'm not sure which place is best.
Yes, these are the pluggable transceivers of network ports, but nothing in the decoding is driver specific. Drivers only return the raw EEPROM bytes through the get_module_eeprom op, and the decoding follows the SFF specifications. The decoder (about 2700 lines) uses ethdev only for the RTE_ETH_MODULE_SFF_* type values and the callback typedef. So ethdev would keep linking it, the same way it depends on net and meter: ethdev depends on the new library, not the other way. rte_eth_dev_get_module_eeprom() and the telemetry command stay in ethdev and call the library. The decoder is also useful for ports which are not ethdev ports: in our firewall, the kernel ports are read with the ethtool ioctls and decoded with a copy of the same code. This already works with rte_eth_module_eeprom_parse(), so a separate library is mostly about keeping ethdev smaller, especially when CMIS is added, which is about the size of the SFF-8636 decoder. Keeping it in ethdev is fine with me too. If you prefer that, I will add CMIS there.
