On 8/18/25 00:24, Morten Brørup wrote:
From: Sunil Kumar Kori [mailto:sk...@marvell.com]
Sent: Monday, 18 August 2025 08.22
On Thu, 14 Aug 2025 11:04:18 +0200
Morten Brørup <m...@smartsharesystems.com> wrote:
From: sk...@marvell.com [mailto:sk...@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).
All that being said, vmxnet3 does mimic a physical device (with a PCI
address).
Ethtool output in Linux shows this:
# ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 1000baseT/Full
10000baseT/Full
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: 10000Mb/s
Duplex: Full
Auto-negotiation: off
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
MDI-X: Unknown
Supports Wake-on: uag
Wake-on: d
Link detected: yes
The link speed may change in a future version.
