DPDK patches and discussions
 help / color / mirror / Atom feed
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).
> >
> >

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