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

[Thomas Monjalon <thomas@monjalon.net>]

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.