Message-ID: <83128442-9e77-482a-ba8f-08883c3f3269@trager.us>
Date: Tue, 18 Nov 2025 22:57:36 -0800
From: Lee Trager <lee@...ger.us>
To: Andrew Lunn <andrew@...n.ch>, Alexander Duyck <alexander.duyck@...il.com>
Cc: Maxime Chevallier <maxime.chevallier@...tlin.com>,
 Susheela Doddagoudar <susheelavin@...il.com>, netdev@...r.kernel.org,
 mkubecek@...e.cz, Hariprasad Kelam <hkelam@...vell.com>,
 Alexander Duyck <alexanderduyck@...com>
Subject: Re: Ethtool: advance phy debug support

On 11/18/25 9:29 AM, Andrew Lunn wrote:

>> Right. With PRBS you already should know what the link partner is
>> configured for. It is usually a manual process on both sides. That is
>> why I mentioned the cable/module EEPROM. The cable will indicate the
>> number of lanes present and the recommended/maximum frequency and
>> modulation it is supposed to be used at.
> But i also expect that is standard ksetting_set behaviour. If user
> space asks you do a specific link mode, you are going to check if it
> is supported and return -EINVAL if it is not. So in the general case,
> all this already exists. I call
>
> ethtool -s eth42 autoneg off 20000baseCR2
>
> and it should check if it is supported, and then configure the MAC,
> PCS and anything else in the path for that link mode. Or return
> -EINVAL if it is not supported.
>
> [I forget the exact ethtool syntax, its not something i use very
> often, to set a specific link mode]

Yes and no. PRBS is a signal integrity test primary used to verify TX 
coefficients with a link partner. There is no way to know what the link 
partner supports when testing. Setup is a manual process and it is 
expected the user will configure both ends correctly. Setup is typically 
mapped to various ethernet settings as that is our goal.

Strictly speaking settings don't have to be mapped to ethernet 
configurations, at least not in our IP. I could use a 3 lane setup 
alternating between NRZ and PAM4 each with different TX coefficients 
despite this not making any sense. This is where the argument comes in 
that PRBS testing and TX coefficients don't belong in ethtool. The 
argument for putting everything in phy is to create a generic interface 
that works for all phys, not just ethernet. That would give us something 
like

phy 00:01.0 lane 0 nrz-tx-coefficent 0 1 8 55 0

phy 00:01.0 lane 1 pam4-tx-cofficent 0 1 9 54 0

phy 00:01.0 lane 2 nrz-tx-officent 0 1 7 45 0

phy 00:01.0 lane 0 start-prbs prbs31

phy 00:01.0 lane 1 start-prbs prbs7

phy 00:01.0 lane 2 start-prbs prbs8

phy 00:01.0 lane 0 get-prbs-stats

...

I don't think there is much value in that which is why I like creating 
an ethernet specific version. It makes a cleaner user interface which 
require less technical details from the user. I like piggy backing off 
of ethtool -s since users are custom to NIC speed, not lanes and mode. 
That would give us something like

ethtool -s eth42 100000baseCR2  - Test fbnic in PAM4 with 2 lanes

ethtool --set-phy-tunable eth42 tx-coefficent 0 1 8 55 0 - Sets the 
tx-coefficent for PAM4, this way users doesn't have to know the mapping 
between mode and speed

ethtool --start-prbs eth42 prbs31 - Start the PRBS31 test

ethtool --get-prbs-stats eth42 - Dump stats collected while testing

ethtool --stop-prbs eth42 - Stop testing

I think that is pretty straight forward for users and allows developers 
to map to whatever backend API they need. I get the argument for a phy 
specific interface but it really complicates things for the user.

>
>> With that you can essentially
>> determine what the correct setup would be to test it as this is mostly
>> just a long duration cable test. The only imitation is if there is
>> something in between such as a PMA/PMD that is configured for 2 lanes
>> instead of 4.
> And the CR2 indicates you want to use 2 lanes. And you would then run
> RPBS on both of them. We could consider additional properties on the
> netlink API to run PRBS on a subset. But would you not actually want
> them all active to see if there is cross talk noise to deal with?
>
>> Yes. Again most of these settings appear to be per-lane in both the IP
>> we have and the IEEE specification. For example it occurs to me that a
>> device could be running a 25G or 50G link over a single QSFP cable,
>> and still have testing enabled for the unused 2 or 3 lanes on the
>> cable potentially assuming the PMA/PMD is a 4 lane link and is only
>> using one or two lanes for the link.
> So that would be 25000baseCR and 50000baseCR2, for the 25G and 50G,
> using 1 lane and 2 lanes, leaving the other 3/2 lanes unused?
In our setup 2500baseCR and 50000baseCR use 1 lane, during testing the 
other lane is unused.
>
> 	Andrew

Powered by blists - more mailing lists