[PATCH v2 0/4] ethdev: add API to decode module EEPROM

[Stephen Hemminger]

On Mon, 28 Sep 2026 10:47:25 +0200
Roman Khromenok <roma55592 at yandex.ru> wrote:

> Since 22.07, ethdev contains SFF-8079, SFF-8472 and SFF-8636 decoders
> for plugin module EEPROM (SFP, QSFP), ported from ethtool.
> They are reachable only through the telemetry command
> /ethdev/module_eeprom, which reads the EEPROM of a DPDK port
> and returns the result as a telemetry dictionary.
> 
> An application which needs to show transceiver information
> (vendor, part number, serial number, optical power) in its own
> interface cannot reuse this code and has to duplicate it.
> It is also common to have some ports managed by DPDK and others
> by the Linux kernel; the kernel returns the EEPROM through the ethtool
> interface with the same module types and layout, but there is no way
> to decode it with DPDK.
> 
> This series exposes the decoders through a small experimental function:
> 
>   int rte_eth_module_eeprom_parse(uint32_t type,
>           const uint8_t *data, uint32_t length,
>           rte_eth_module_eeprom_field_cb cb, void *arg);
> 
> Each decoded field is reported to the callback as a pair of strings,
> the same names and values as in the telemetry output.
> The function does not access any device and does not require
> EAL initialization.
> 
> Patch 1 makes the decoders write to a callback instead of
> the telemetry dictionary; the telemetry output is unchanged.
> Patch 2 adds the buffer length checks needed by a public API:
> currently SFF-8079 and SFF-8472 decoders do not receive the length.
> Patch 3 adds the API with documentation and release notes.
> Patch 4 adds unit tests.
> 
> v2:
> - patch 2: do not read the SFF-8636 alarm and warning thresholds
>   from page 03h when only 256 bytes are available (out of bounds read
>   found by ASan in the new unit test).
> 
> Roman Khromenok (4):
>   ethdev: decouple SFF module EEPROM decoders from telemetry
>   ethdev: check module EEPROM length before decoding
>   ethdev: add API to decode module EEPROM
>   test: add ethdev module EEPROM decoding tests
> 
>  .mailmap                                |   1 +
>  app/test/meson.build                    |   1 +
>  app/test/test_ethdev_module_eeprom.c    | 285 ++++++++++++++++++++++++
>  doc/guides/prog_guide/ethdev/ethdev.rst |  44 ++++
>  doc/guides/rel_notes/release_26_11.rst  |   7 +
>  lib/ethdev/rte_ethdev.c                 |  20 ++
>  lib/ethdev/rte_ethdev.h                 |  50 +++++
>  lib/ethdev/sff_8079.c                   |  20 +-
>  lib/ethdev/sff_8472.c                   |   2 +-
>  lib/ethdev/sff_8636.c                   |  74 +++---
>  lib/ethdev/sff_common.c                 |  14 +-
>  lib/ethdev/sff_common.h                 |  14 +-
>  lib/ethdev/sff_telemetry.c              |  94 +++++---
>  lib/ethdev/sff_telemetry.h              |  25 ++-
>  14 files changed, 552 insertions(+), 99 deletions(-)
>  create mode 100644 app/test/test_ethdev_module_eeprom.c
> 


AI review had good point that bugfix should be first patch and cc to stable

Review: [PATCH v2 0/4] ethdev: module EEPROM decoding API

Each commit builds with -Dwerror=true, and ethdev_module_eeprom
passes.

Patch 2 is a real bug fix, not just preparation. Before this series,
sff_8636_dom_parse() reads the page 03h thresholds (0x200-0x247)
unconditionally, while the telemetry handler allocates exactly
minfo.eeprom_len. Several in-tree drivers report less than 640
bytes for QSFP modules: i40e reports QSFP+ as SFF-8436 with 256,
bnxt reports flat memory QSFP28 with 256, xsc reports 256 or 512.
/ethdev/module_eeprom on those ports reads past the end of the heap
buffer. This has been present since 22.07.

Please make the fix the first patch, standalone against the current
rte_tel_data code, so it can go to stable:

  Fixes: c42754fd581a ("ethdev: support SFF-8636 module telemetry")
  Cc: stable at dpdk.org

The commit message should say what it fixes (heap over-read in the
telemetry handler) rather than describe it as preparation. The
sff_output refactor and the new API then go on top.


Patch 1/4 ethdev: decouple SFF module EEPROM decoders from telemetry

Info
- struct sff_output, and after patch 2 sff_decode_module_eeprom(),
  are no longer telemetry specific but still live in
  sff_telemetry.[ch]. Every decoder still calls
  ssf_add_dict_string(), a misspelled telemetry name for what is now
  a one line callback dispatch. This patch already touches every
  signature; consider renaming it (e.g. sff_output_field()) and
  moving the generic parts to sff_common.h.


Patch 2/4 ethdev: check module EEPROM length before decoding

Warning
- Missing Fixes: and Cc: stable at dpdk.org, and it depends on the
  sff_output refactor in patch 1, so it cannot be backported as is.
  See summary above.


Patch 3/4 ethdev: add API to decode module EEPROM

Warning
- A2_OFFSET_TO_RXPWRx() in sff_8472.c casts the byte buffer to
  const uint32_t * and befloattoh() dereferences it. The RXPWR
  calibration offsets are 4-byte aligned relative to data, so this
  only worked because the telemetry buffer comes from calloc(). The
  new API accepts any const uint8_t * from the application; a
  misaligned buffer makes this an unaligned load (UB, UBSan reports
  it, traps on strict alignment targets). Reached when the module
  sets the externally calibrated bit (byte 92, bit 4). Read with
  memcpy() into a uint32_t, then rte_be_to_cpu_32().

Info
- The field names and value strings become the de facto API. The
  test in patch 4 already pins "Rcvr signal avg optical
  power(Channel 1)", missing space included, so fixing that later
  breaks applications that match on names. Either clean up the
  names before exposing them, or state in the doxygen that names
  and value formats are for display only and may change.
  Applications wanting numeric values (RX power, temperature) must
  parse "0.6724 mW / -1.72 dBm"; worth considering while the API is
  still experimental. A void callback also gives the caller no way
  to stop early.

- The doxygen documents the SFF-8472 length rule but not the
  SFF-8636 one: thresholds and alarm flags are decoded only when
  length == RTE_ETH_MODULE_SFF_8636_MAX_LEN exactly. With an
  application supplied buffer, an oversized length silently drops
  them. Use >= and document it next to the SFF-8472 note.

- ethdev.rst and the release note say Linux ethtool data uses the
  same types and layout. That holds for the ETHTOOL_GMODULEINFO /
  ETHTOOL_GMODULEEEPROM ioctls. The netlink MODULE_EEPROM_GET
  interface is page addressed and carries no module type, so its
  data must be reassembled first. Name the ioctl.

- "Plugin module" in the doc heading and release note; the usual
  term is "pluggable module".


Patch 4/4 test: add ethdev module EEPROM decoding tests

Info
- No case covers SFF-8636 with 640 bytes and paging present (byte 2
  bit 2 clear), which is the path patch 2 changes. Add one checking
  "Alarm/warning flags implemented" is "Yes" and a threshold field
  is decoded.

- The test is registered as ethdev_module_eeprom; nearly all fast
  tests use the _autotest suffix.