Re: [PATCH v2 0/4] ethdev: report module signal status flags

[Stephen Hemminger <stephen@networkplumber.org>]

On Fri, 09 Oct 2026 22:34:37 +0200
Thomas Monjalon <thomas@monjalon.net> 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).