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

[Ivan Malov]

On Mon, 18 Aug 2025, Morten Brørup wrote:

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

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