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

[Morten Brørup]

> From: Ivan Malov [mailto:ivan.malov at arknetworks.am]
> Sent: Monday, 18 August 2025 10.13
> 
> Hi Morten,
> 
> On Mon, 18 Aug 2025, Morten Brørup wrote:
> 
> <snip>
> 
> >
> > 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.
> 
> I can imagine the user having a 2-port NIC (and 2 PFs exposed to the host by
> default), with only the 1st port having a cable plugged into it, where some
> traffic received by the 1st port is intercepted by a 'transfer' flow rule to
> be
> redirected to the 2nd PF. While the 2nd PF in this case serves some fraction
> of
> traffic, its LINK_TYPE (or, maybe LINK_TECH) is still 'NONE', as its own
> associated network port (the 2nd port) has got no cable.

In this scenario, although the 2nd port has no socket to plug/unplug a cable, I would consider the 2nd port as connected by internal (on-chip) wires, and use the "OTHER" connector type to describe that on-chip connection.

But what happens if a cable is also plugged into the 2nd port... now it has two connectors simultaneously. The same could occur to a NIC that is exposed to DPDK as a single port, but is actually connected via a port multiplexer (e.g. a 5-port switch chip) to multiple physical ports.

> 
> Also, perhaps port representors for VFs that can act as 'patch panel' to, say,
> set MTU on the target VF, but do not expose Rx/Tx to the DPDK application can
> have the link type indicate 'NONE', but this is a bit of a stretch, of course.

Yeah, "NONE" might be appropriate here.
So the question is: If "NONE" is only relevant for exotic cases like this, should we omit it for simplicity?

> 
> Maybe I'm very wrong in fact, so feel free to disregard my notes.

Good, creative input!

> 
> Thank you.
> 
> >
> > "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).
> >
> >