Message-ID: <CAKgT0UdH_t2FO7mXWyR3V2Lo0HzKUudUF8HciYjFrx7fNUJkyA@mail.gmail.com>
Date: Wed, 19 Nov 2025 09:22:15 -0800
From: Alexander Duyck <alexander.duyck@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Lee Trager <lee@...ger.us>, 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 Wed, Nov 19, 2025 at 6:20 AM Andrew Lunn <andrew@...n.ch> wrote:
>
> > 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
>
> Please could you always make it clear which definition of phy you are
> using. generic phy, or phylib phy. Here you appear to be meaning
> generic phy. For TX coefficients, that mostly makes sense to me.
>
> There is maybe one exception i can think of, the Aquantia phylib
> phy. You have a setup of a SoC with a MAC, PCS, SERDES lane, and then
> a discrete aquantia BaseT PHY which has its own PCS and the all the
> usual analogue stuff to put the bitstream on twisted pairs. There are
> undocumented registers in phylib PHY to configuring the eye etc. There
> currently are no phylib phys with embedded generic phys. There is no
> reason it cannot be done, just nobody has done it so far. And there is
> no reason this is special to the aquantia PHY, other phylib phys using
> a SERDES towards the MAC could also have such registers.

I think part of the issue is the fact that a PMA/PMD and a PHY get
blurred due to the fact that a phylib driver will automatically bind
to said PMA/PMD. I partially blame the legacy setup versus the c45
device partitioning for the confusion. For the most part our generic
phy is a PMD. That is why I am attempting to portray it in the fbnic
driver as such using a c45 interface.

Especially as we start getting into the higher speeds such as 50R1 and
all those PAM4 based variants we are going to run into things like
link training which have to be handled somehow as normally that is the
responsibility of the PMD which is a sub-component within the PHY.

> > 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
>
> Yep, that i like.

I'm not a huge fan as it actually is hiding a bunch of the details
under the hood. Also it blocks several specific test types that may be
needed. It may work fine for a cable test for a specific link config,
but it is only touching the tip of the iceberg in terms of what may be
needed for PRBS testing.

A good metaphor for something like this would be taking a car for a
test drive versus balancing the tires. In the case of the PRBS test we
may want to take the individual lanes and test them one at a time and
at various frequencies to deal with potential cross talk and such. It
isn't until we have verified everything is good there that we would
then want to take the combination of lanes, add FEC and a PCS, and try
sending encoded traffic over it. That said, maybe I am arguing the
generic phy version of this testing versus the Ethernet phy version of
it.

> >
> > 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
>
> And this i don't. --set-phy-tunable is for a phylib PHY. Its for a
> device which converts a bitstream to analogue signals on twisted
> pair. fbnic does not have such a device. What you do have is a generic
> phy, even if currently you don't model it in Linux with an actual
> generic phy. But that is 'just code'. And the generic phy API does
> have some networking specific APIs, so i don't see why you cannot add
> another API for enumerating and setting TX coefficients.

I don't disagree with you on this. It is one of the reasons why I
mentioned that the generic phy would end up being a superset of
anything the phylib phy could do. The phylib setups are focused on
things like interface type and link configuration. However those don't
really apply to things like a PRBS test which is mostly about just
generating and verifying a signal on individual lanes.

> The other problem with what you have above is you only reference the
> netdev, and not which of the multiple generic phys that netdev might
> have. Think of the SoC-PCS-generic_phy-lane-generic_phy-PCS-BaseT
> system above. Both the SoC and the phylib phy can have coefficient
> registers. You need to enumerate which you want to set.
>
> For a long time we had this same problem with phylib, a netdev can
> have multiple phylib phys, but the kAPI had no way to indicate which
> of those phys you wanted to configure. We mostly have that solved now,
> but we should learn from that experience, and not repeat the same
> problem.

True. In our case we have both PCS capability for PRBS and generic phy
capability for that. Being able to control those at either level would
be useful. In my mind I was thinking it might be best for us to go
after PCS first in the case of fbnic due to the fact that the PMD is
managed by the firmware.

> > ethtool --start-prbs eth42 prbs31 - Start the PRBS31 test
>
> and this has the same problem, which prbs associated to the netdev do
> you want to run prb31? There could be one in the SoC PCS, the BaseT
> PCS pointing back towards the Soc, and maybe in the BaseT PHY pointing
> towards the line?
>
> So you need something like
>
> ethtool --list-prbs eth42
>
> to list all the PRBSes associated to the netdev, maybe also listing
> its capabilities. And then something like:
>
> ethtool --start-prbs eth42 --prbs 1 --mode prbs31
>
> to make use of the 1st PRBS, rather than the 0th.
>
>         Andrew

Really this gets at the more fundamental problem. We still don't have
a good way to break out all the components within the link setup.
Things like lanes are still an abstract concept in the network setup
and aren't really represented at all in the phylink/phylib code. Part
of the reason for me breaking out the generic PHY as a PMD in fbnic
was because we needed a way to somehow include the training state for
it into the total link state.

I suspect to some extent we would need to look at something similar
for all the PRBS testing and such to provide a way for the PCS, FEC,
etc to all play with a generic phy in the setup and have it make sense
to it as a network device.

Powered by blists - more mailing lists