DPDK patches and discussions
 help / color / mirror / Atom feed
From: Sunil Kumar Kori <skori@marvell.com>
To: "Morten Brørup" <mb@smartsharesystems.com>,
	"Stephen Hemminger" <stephen@networkplumber.org>
Cc: Thomas Monjalon <thomas@monjalon.net>,
	Ferruh Yigit <ferruh.yigit@amd.com>,
	Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
	"dev@dpdk.org" <dev@dpdk.org>,
	Nithin Kumar Dabilpuram <ndabilpuram@marvell.com>,
	Jerin Jacob <jerinj@marvell.com>
Subject: RE: [EXTERNAL] Re: [PATCH v2 1/1] ethdev: add support to provide link type
Date: Wed, 13 Aug 2025 07:42:36 +0000	[thread overview]
Message-ID: <CO6PR18MB3860D708EC9F561A28AD5B75B42AA@CO6PR18MB3860.namprd18.prod.outlook.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9FCD8@smartserver.smartshare.dk>

Hi Morten and Stephen,

To address your comments, I revisited to change and concluded following points:

1. Extending Link Types Alongside Legacy:

I'm aligned on extending link types while retaining legacy support — No concerns here. I will add following link type to the list.

	- NONE
	- TP
	- AUI
	- MII
	- FIBRE
	- BNC
	- DA
	- SGMII
	- QSGMII
	- XFI
	- SFI
	- XLAUI
	- GAUI
	- SFI
	- XAUI
	- XLAUI
	- GAUI
	- GBASE
	- CAUI
	- LAUI
	- SFP
	- SFP_DD
	- SFP_PLUS
	- SFP28
	- QSFP
	- QSFP_PLUS
	- QSFP28
	- QSFP56
	- QSFP_DD
	- OTHER

2. ABI Breakage Concern:
"I'm not entirely clear on how this change results in an ABI breakage, as the new bit field is added within the existing space. Could you please elaborate on the specific aspects that lead to ABI incompatibility ?" Worst case, since this is 25.11, API breakage is fine.

3. Reporting Link Type by Drivers:
General APIs often expose capabilities, and drivers selectively implement them. Setting the link type to 0 when unsupported is a reasonable fallback.
Ensuring 0 is treated as “unknown” or “not supported” rather than misleading.

4. Regarding management interfaces for PHYs or modules:
This patch does not introduce any management APIs for PHYs or modules. Its sole purpose is to expose the link type as an additional attribute to the user. Any support for PHY or module management should be handled separately and is outside the scope of this change.

Thanks
Sunil Kumar Kori

> > From: Sunil Kumar Kori [mailto:skori@marvell.com]
> > Sent: Tuesday, 10 June 2025 07.02
> >
> > > On Fri, 6 Jun 2025 11:54:52 +0200
> > > Morten Brørup <mb@smartsharesystems.com> wrote:
> > >
> > > > > From: skori@marvell.com [mailto:skori@marvell.com]
> > > > > Sent: Friday, 6 June 2025 11.28
> > > > >
> > > > > From: Sunil Kumar Kori <skori@marvell.com>
> > > > >
> > > > > Adding link type parameter to provide the type of port like
> > > > > twisted pair, fibre etc.
> > > > >
> > > > > Also added an API to convert the RTE_ETH_LINK_TYPE_XXX to a
> > > > > readable string.
> > > > >
> > > > > Signed-off-by: Nithin Dabilpuram <ndabilpuram@marvell.com>
> > > > > Signed-off-by: Sunil Kumar Kori <skori@marvell.com>
> > > > > ---
> > > > > +/**@{@name PORT type
> > > > > + * Ethernet port type
> > > > > + */
> > > > > +#define RTE_ETH_LINK_TYPE_NONE  0x00 /**< Not defined */
> > > > > +#define RTE_ETH_LINK_TYPE_TP    0x01 /**< Twisted Pair */
> > > > > +#define RTE_ETH_LINK_TYPE_AUI   0x02 /**< Attachment Unit Interface */
> > > > > +#define RTE_ETH_LINK_TYPE_MII   0x03 /**< Media Independent Interface
> > > > > */
> > > > > +#define RTE_ETH_LINK_TYPE_FIBRE 0x04 /**< Fibre */
> > > > > +#define RTE_ETH_LINK_TYPE_BNC   0x05 /**< BNC */
> > > > > +#define RTE_ETH_LINK_TYPE_DA    0x06 /**< Direct Attach copper */
> > > > > +#define RTE_ETH_LINK_TYPE_OTHER 0x1F /**< Other type */ /**@}*/
> > > >

  reply	other threads:[~2025-08-13  7:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-05 11:31 [PATCH] " skori
2025-06-05 15:26 ` Stephen Hemminger
2025-06-06  9:28 ` [PATCH v2 1/1] " skori
2025-06-06  9:54   ` Morten Brørup
2025-06-06 15:23     ` Stephen Hemminger
2025-06-10  5:02       ` [EXTERNAL] " Sunil Kumar Kori
2025-06-10  6:45         ` Morten Brørup
2025-08-13  7:42           ` Sunil Kumar Kori [this message]
2025-08-13  8:42   ` [PATCH] " skori
2025-08-13  8:43   ` [PATCH v3 1/1] " skori
2025-08-13 10:25     ` Thomas Monjalon
2025-08-13 12:16       ` Ivan Malov
2025-08-13 14:17         ` Stephen Hemminger
2025-08-13 15:04     ` 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=CO6PR18MB3860D708EC9F561A28AD5B75B42AA@CO6PR18MB3860.namprd18.prod.outlook.com \
    --to=skori@marvell.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@amd.com \
    --cc=jerinj@marvell.com \
    --cc=mb@smartsharesystems.com \
    --cc=ndabilpuram@marvell.com \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    /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;
as well as URLs for NNTP newsgroup(s).