Re: [PATCH net-next 1/6] ethtool: Extend link modes settings uAPI with lanes

From: Edwin Peer <edwin.peer@broadcom.com>
To: Jiri Pirko <jiri@resnulli.us>
Cc: Ido Schimmel <idosch@idosch.org>, netdev <netdev@vger.kernel.org>,
	"David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, Jiri Pirko <jiri@nvidia.com>,
	Danielle Ratson <danieller@nvidia.com>,
	Andrew Lunn <andrew@lunn.ch>,
	f.fainelli@gmail.com, Michal Kubecek <mkubecek@suse.cz>,
	mlxsw <mlxsw@nvidia.com>, Ido Schimmel <idosch@nvidia.com>
Subject: Re: [PATCH net-next 1/6] ethtool: Extend link modes settings uAPI with lanes
Date: Wed, 2 Dec 2020 09:53:51 -0800	[thread overview]
Message-ID: <CAKOOJTwENt5HOon4rsGwB+PoJUxq1a1pWzNXVJsWmhe8198P0A@mail.gmail.com> (raw)
In-Reply-To: <20201202100922.GM3055@nanopsycho.orion>

[-- Attachment #1: Type: text/plain, Size: 1867 bytes --]

On Wed, Dec 2, 2020 at 2:09 AM Jiri Pirko <jiri@resnulli.us> wrote:

> >I'm not suggesting the port split be dynamic at all. I'm suggesting that if
> >the admin wants or needs to force PAM4 on a port that would otherwise
> >be able to achieve the given speed using more lanes with NRZ, then the
> >admin should split the port, so that it has fewer lanes, in order to make
> >that intent clear (or otherwise configure the port to have fewer lanes
> >attached, if you really don't want to or can't create the additional split
> >port).
>
> Okay, I see your point now. The thing is, the port split/unsplit causes
> a great distubance. Meaning, the netdevs all of the port
> disappear/reappear. Now consider following example:

I guess that's a detail of the present implementation and/or device
capabilities (I'm not particularly familiar), but presumably it is at least
possible, in principle, to modify a device's port config without taking
down the netdev. That said, after spending more time thinking about
this, I'm coming around to the idea of being able to explicitly set
encoding (not lanes) via ethtool. And, in this context, by encoding,
I technically mean line code signalling, not symbol encoding.

Although it does for today's link modes, the number of lanes does
not generally imply signalling mode. In future we may have PAM8
signalling and then the present proposal of deriving the signalling
mode for a given speed from the lane count falls down. We should
be specifying signalling mode via ethtool instead of lanes.

Alternatively, we need to be specifying the fully defined link mode.
But, doing so is fraught with other issues, including how to represent
it in the interface and the fact that the user doesn't necessarily want
to specify physical media in these cases, something that is implied
by the full link mode definition.

Regards,
Edwin Peer

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4160 bytes --]