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/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.

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.

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.

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

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).
>
>