On Mon, 18 Aug 2025, Morten Brørup wrote:
From: Ivan Malov [mailto:ivan.ma...@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.
That 'flow' connection still cannot be considered a full connector, as it cherry
picks certain traffic, I presume, so still doesn't fall into 'OTHER' category.
However, how about 'null' PMD with 'no-rx' option passed? Is it 'NONE'? There's
also file-based use case of 'pcap' PMD, but that may be recognised as 'OTHER'.
Thank you.
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).
