09/10/2026 21:21, Roman Khromenok: > On Fri, 9 Oct 2026, Stephen Hemminger wrote: > > Applied to next-net. > > > > I wonder if the eeprom really belongs in its on library, really it is not > > part of standard ethdev. > > Thanks, Stephen. > > Agreed, the decoder does not need a device: it only parses a buffer > and works without EAL. Only rte_eth_dev_get_module_eeprom() and the > telemetry command are really ethdev. > > If Thomas and Andrew are fine with it, I can send an RFC for 27.03 > moving the SFF decoders into a small library with its own API, with > the ethdev telemetry command on top of it. rte_eth_module_eeprom_parse() > is experimental, so it can stay as a thin wrapper or be removed. > A separate library would also be the place for CMIS (QSFP-DD, OSFP) > decoding later, which does not fit the SFF naming, so a neutral name > like lib/xcvr may be better than lib/sff. > > I am willing to maintain this library.
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.
