09/10/2026 22:57, Roman Khromenok: > 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.
Having it separate would be similar to the net library, yes. The ethtool case is convincing me to move it to a separate library.
