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

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

> From: Jochen Behrens [mailto:jochen.behrens@broadcom.com]
> Sent: Tuesday, 19 August 2025 00.42
> 
> On 8/18/25 00:24, Morten Brørup wrote:
> >> 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/eth
> tool.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.

Virtual NICs behaving like physical NICs is great for backwards compatibility.

However:
The reported link speed affects the traffic path selection for e.g. Spanning Tree.
And it may limit the egress bandwidth of a guest with a traffic shaper attached to the vNIC, if the shaper adapts to the link speed.

In a perfect world, the link speed reported by the vNIC driver (in the guest) would reflect the speed of the physical port the vNIC is connected to (in the host system).
And when a vNIC is connected to a bridge in the host, that bridge may be connected to e.g. a LACP trunk of e.g. 2*10 Gbit/s links. In this case, the vNIC could report a link speed of 20 Gbit/s.
But if the bridge in the host is only connected to other guests, and no physical port, the inter-guest bandwidth should not be limited to 10 or 20 Gbit/s.
And if the bridge is both connected to other guests and physical ports, it becomes impossible to report a proper speed.

In short: Reporting the link speed of a vNIC is not simple.