From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Ivan Malov" <ivan.malov@arknetworks.am>
Cc: "Sunil Kumar Kori" <skori@marvell.com>,
"Stephen Hemminger" <stephen@networkplumber.org>,
"Thomas Monjalon" <thomas@monjalon.net>,
"Andrew Rybchenko" <andrew.rybchenko@oktetlabs.ru>,
<dev@dpdk.org>,
"Nithin Kumar Dabilpuram" <ndabilpuram@marvell.com>
Subject: RE: [EXTERNAL] Re: [PATCH v4 1/1] ethdev: add support to provide link type
Date: Mon, 18 Aug 2025 10:39:11 +0200 [thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9FE44@smartserver.smartshare.dk> (raw)
In-Reply-To: <3f847399-a91c-a6c1-48db-33f83fca9994@arknetworks.am>
> From: Ivan Malov [mailto:ivan.malov@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).
> >
> >
next prev parent reply other threads:[~2025-08-18 8:39 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-05 11:31 [PATCH] " skori
2025-06-05 15:26 ` Stephen Hemminger
2025-06-06 9:28 ` [PATCH v2 1/1] " skori
2025-06-06 9:54 ` Morten Brørup
2025-06-06 15:23 ` Stephen Hemminger
2025-06-10 5:02 ` [EXTERNAL] " Sunil Kumar Kori
2025-06-10 6:45 ` Morten Brørup
2025-08-13 7:42 ` Sunil Kumar Kori
2025-08-13 8:42 ` [PATCH] " skori
2025-08-13 8:43 ` [PATCH v3 1/1] " skori
2025-08-13 10:25 ` Thomas Monjalon
2025-08-13 12:16 ` Ivan Malov
2025-08-13 14:17 ` Stephen Hemminger
2025-08-14 5:09 ` [EXTERNAL] " Sunil Kumar Kori
2025-08-13 15:04 ` Stephen Hemminger
2025-08-14 8:10 ` [PATCH v4 " skori
2025-08-14 9:04 ` Morten Brørup
2025-08-14 16:15 ` Stephen Hemminger
2025-08-18 6:21 ` [EXTERNAL] " Sunil Kumar Kori
2025-08-18 7:24 ` Morten Brørup
2025-08-18 8:13 ` Ivan Malov
2025-08-18 8:39 ` Morten Brørup [this message]
2025-08-18 8:50 ` Ivan Malov
2025-08-18 6:20 ` Sunil Kumar Kori
2025-08-14 16:07 ` Stephen Hemminger
2025-08-18 6:13 ` [EXTERNAL] " Sunil Kumar Kori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=98CBD80474FA8B44BF855DF32C47DC35E9FE44@smartserver.smartshare.dk \
--to=mb@smartsharesystems.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=dev@dpdk.org \
--cc=ivan.malov@arknetworks.am \
--cc=ndabilpuram@marvell.com \
--cc=skori@marvell.com \
--cc=stephen@networkplumber.org \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).