RE: [EXTERNAL] Re: [PATCH v4 1/1] ethdev: add support to provide link type

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Sunil Kumar Kori [mailto:skori@marvell.com]
> Sent: Monday, 18 August 2025 08.22
> 
> > On Thu, 14 Aug 2025 11:04:18 +0200
> > Morten Brørup <mb@smartsharesystems.com> wrote:
> >
> > > > From: skori@marvell.com [mailto:skori@marvell.com]
> > > > Sent: Thursday, 14 August 2025 10.10
> > > >
> > > > 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.
> > >
> > > Please consider if "connector" is a better name than "link type", if this
> is related
> > to physical interfaces only.
> > > E.g. is there an "LACP" link type for link aggregates (bonded links)?
> > >
> > > Also, should a "virtual" link type (or connector) be added for
> > TAP/Virtio/VMXNET3/ring and similar non-physical interfaces?
> > >
> > > More comments inline below.
> >
> > My preference is that a new feature like this follow what other commands and
> > standards do.
> > There is Linux ethtool as the most common example.
> > Also, there is probably something IEEE standard but that is behind stupid
> > paywall.
> >
> > Ethtool on real NIC.
> > # ethtool enp87s0
> > Settings for enp87s0:
> > 	Supported ports: [ TP ]
> > 	Supported link modes:   10baseT/Half 10baseT/Full
> > 	                        100baseT/Half 100baseT/Full
> > 	                        1000baseT/Full
> > 	                        2500baseT/Full
> > 	Supported pause frame use: Symmetric
> > 	Supports auto-negotiation: Yes
> > 	Supported FEC modes: Not reported
> > 	Advertised link modes:  10baseT/Half 10baseT/Full
> > 	                        100baseT/Half 100baseT/Full
> > 	                        1000baseT/Full
> > 	                        2500baseT/Full
> > 	Advertised pause frame use: Symmetric
> > 	Advertised auto-negotiation: Yes
> > 	Advertised FEC modes: Not reported
> > 	Speed: 2500Mb/s
> > 	Duplex: Full
> > 	Auto-negotiation: on
> > 	Port: Twisted Pair
> > 	PHYAD: 0
> > 	Transceiver: internal
> > 	MDI-X: off (auto)
> > 	Supports Wake-on: pumbg
> > 	Wake-on: g
> >         Current message level: 0x00000007 (7)
> >                                drv probe link
> > 	Link detected: yes
> >
> > And on virtio
> > # ethtool enp1s0
> > Settings for enp1s0:
> > 	Supported ports: [  ]
> > 	Supported link modes:   Not reported
> > 	Supported pause frame use: No
> > 	Supports auto-negotiation: No
> > 	Supported FEC modes: Not reported
> > 	Advertised link modes:  Not reported
> > 	Advertised pause frame use: No
> > 	Advertised auto-negotiation: No
> > 	Advertised FEC modes: Not reported
> > 	Speed: Unknown!
> > 	Duplex: Unknown! (255)
> > 	Auto-negotiation: off
> > 	Port: Other
> > 	PHYAD: 0
> > 	Transceiver: internal
> > 	Link detected: yes
> 
> Agreed, hence adding one more type RTE_ETH_LINK_TYPE_OTHER to align.

Ethtool has both NONE and OTHER:
https://git.kernel.org/pub/scm/network/ethtool/ethtool.git/tree/uapi/linux/ethtool.h#n2242

Ethtool doesn't have a 3rd value UNKNOWN, and I think having a 3rd value complicates things too much.

I still think we should consider OTHER==UNKNOWN, and that NONE (having no connector) cannot happen and thus should be omitted.
Having more than one of these adds complexity, and I fail to see the benefit.

"Because Ethtool also has NONE" is not a good argument. Linux has plenty of obsolete stuff, which we don't need to copy to DPDK.
However, referring to the reason why Ethtool also has NONE (in addition to OTHER) might reveal a valid argument for having it in DPDK too.

Anyway, if we have more than one value (in addition to the actual physical connector values), they need good descriptions, so it is crystal clear what the difference is between NONE and OTHER (and UNKNOWN, if we proceed with this 3rd value).