On Fri, 09 Oct 2026 22:34:37 +0200 Thomas Monjalon <[email protected]> wrote:
> 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. Agree. One of the concerns is that meson can't handle cross dependencies so it needs to be ethdev -> eeprom (or vice versa).
