From: Thomas Monjalon <thomas@monjalon.net>
To: Roman Khromenok <roma55592@yandex.ru>
Cc: dev@dpdk.org, stephen@networkplumber.org, andrew.rybchenko@oktetlabs.ru
Subject: Re: [PATCH v2 0/4] ethdev: report module signal status flags
Date: Fri, 09 Oct 2026 22:34:37 +0200 [thread overview]
Message-ID: <QfuRvLIpRPi5pHmcYtqGrA@monjalon.net> (raw)
In-Reply-To: <20261009192113.534604-1-roma55592@yandex.ru>
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.
next prev parent reply other threads:[~2026-10-09 20:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-08 8:23 [PATCH 0/4] ethdev: report module signal status flags Roman Khromenok
2026-10-08 8:23 ` [PATCH 1/4] ethdev: report SFF-8636 lane " Roman Khromenok
2026-10-08 8:23 ` [PATCH 2/4] test: check " Roman Khromenok
2026-10-08 8:23 ` [PATCH 3/4] ethdev: report SFF-8472 Rx LOS and Tx fault state Roman Khromenok
2026-10-08 8:23 ` [PATCH 4/4] test: check " Roman Khromenok
2026-10-08 17:45 ` [PATCH 0/4] ethdev: report module signal status flags Stephen Hemminger
2026-10-08 18:02 ` [PATCH v2 " Roman Khromenok
2026-10-08 18:02 ` [PATCH v2 1/4] ethdev: report SFF-8636 lane " Roman Khromenok
2026-10-08 18:02 ` [PATCH v2 2/4] test: check " Roman Khromenok
2026-10-08 18:02 ` [PATCH v2 3/4] ethdev: report SFF-8472 Rx LOS and Tx fault state Roman Khromenok
2026-10-08 18:02 ` [PATCH v2 4/4] test: check " Roman Khromenok
2026-10-09 18:22 ` [PATCH v2 0/4] ethdev: report module signal status flags Stephen Hemminger
2026-10-09 19:21 ` Roman Khromenok
2026-10-09 20:34 ` Thomas Monjalon [this message]
2026-10-09 20:57 ` Roman Khromenok
2026-10-09 21:59 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=QfuRvLIpRPi5pHmcYtqGrA@monjalon.net \
--to=thomas@monjalon.net \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=dev@dpdk.org \
--cc=roma55592@yandex.ru \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox