Ethtool : PRBS feature

Ethtool : PRBS feature

[Das, Shubham]

Hi All,

I'm looking for feedback on a potential extension to ethtool for controlling Ethernet PHY link characterization using PRBS generation and error injection.
PRBS is a port level configuration and ethtool ?phy-test will provide control interface at every port-level.

PRBS is an IEEE standard, and almost all Ethernet PHY SerDes comes with PRBS generator and receiver to assist physical link characterization.
In addition to PRBS sequence, we want to support provide SW control knobs to insert fixed number of errors, retrieve the bit error count, and clear them as needed.
With this, we are trying to standardize a multi-decade technology PRBS, so every Ethernet vendor can get benefited and replace the device specific custom tools.
From Ethernet designer point-of-view, it helps identify, fine tune, and make the ethernet communication better and stable. 
From end-user point of view, it helps gather debug data when something is not working at expected speeds.

Typical operations include:

ethtool --phy-test eth1 tx-prbs prbs7
ethtool --phy-test eth2 rx-prbs prbs7

ethtool --phy-test eth2 bert start
ethtool --phy-test eth2 bert stop
ethtool --phy-test eth2 stats
ethtool --phy-test eth2 clear-stats

ethtool --phy-test eth1 inject-error 1
ethtool --phy-test eth1 inject-error 1e-3

ethtool --phy-test eth1 tx-prbs off
ethtool --phy-test eth2 rx-prbs off


Approach would be to add a generic ethtool netlink API for PHY/SerDes and allow drivers to implement the operations directly. 
Conceptually:
       ethtool ⇒ ethtool netlink ⇒ driver-specific implementation

The intent would be to provide a common userspace interface while allowing implementations in NIC drivers.

Before proceeding further, I would appreciate feedback on:

1. Whether ethtool is considered the appropriate userspace interface for these functionality
2. Whether similar work has been proposed previously.

Thanks,
Shubham D

Re: Ethtool : PRBS feature

[Andrew Lunn]

> 2. Whether similar work has been proposed previously.

There was a presentation at netdev conf last year about this topic,
and how you use it to configure SERDES eyes. And then a long
discussion on the netdev mailing afterwards. You should read the
discussion, and incorporate the ideas. There was a couple of points
raised:

SERDES are also used for PCIe, USB, SATA, and they have similar
capabilities to a SERDES used for networking. Do we want a networking
specific solution, or something more generic?

You need to include lane information, since there can be 1, 2 or 4
lanes involved, and you need to specify which lane you want to test.

      Andrew

RE: Ethtool : PRBS feature

[Das, Shubham]

Hi Andrew,

Thanks for the feedback.

Yes, for multi-lane ports we can accept the lane number as an argument like:

ethtool --phy-test eth1 lane 0 tx-prbs prbs7
ethtool --phy-test eth2 lane 0 rx-prbs prbs7

We referred to "Lee Trager's" "Open-Source Tooling for PHY Management and Testing" session:
https://netdevconf.info/0x19/sessions/talk/open-source-tooling-for-phy-management-and-testing.html?.
We have been trying to reach "Lee Trager" to seek more input, latest update on the approach and understand if there is a parallel effort in active so we can collaborate.
If you can, please help me connect with "Lee Trager" and others who expressed interest in Ethernet PRBS. We are happy to align and start implementation.

About standardizing across other bus like PCIe and USB, I had a quick discussion with our internal designers, but I didn't observe any such SW-level config knobs interest. 
Looks like Ethernet has clear interest and we are joining that Ethernet PRBS community too.

Ethernet PRBS configuration and diagnostics support is well established and already widely used in existing Ethernet SERDES deployments.
We think Ethernet is the most natural starting point within netdev, as it aligns with current driver practice and existing validation workflows. 

Thanks,
Shubham D


> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: 11 June 2026 21:14
> To: Das, Shubham <shubham.das@intel.com>
> Cc: netdev@vger.kernel.org; mkubecek@suse.cz; D H, Siddaraju
> <siddaraju.dh@intel.com>; Chintalapalle, Balaji <balaji.chintalapalle@intel.com>
> Subject: Re: Ethtool : PRBS feature
> 
> > 2. Whether similar work has been proposed previously.
> 
> There was a presentation at netdev conf last year about this topic,
> and how you use it to configure SERDES eyes. And then a long
> discussion on the netdev mailing afterwards. You should read the
> discussion, and incorporate the ideas. There was a couple of points
> raised:
> 
> SERDES are also used for PCIe, USB, SATA, and they have similar
> capabilities to a SERDES used for networking. Do we want a networking
> specific solution, or something more generic?
> 
> You need to include lane information, since there can be 1, 2 or 4
> lanes involved, and you need to specify which lane you want to test.
> 
>       Andrew

Re: Ethtool : PRBS feature

[Alexander H Duyck]

On Tue, 2026-06-16 at 12:14 +0000, Das, Shubham wrote:
> Hi Andrew,
> 
> Thanks for the feedback.
> 
> Yes, for multi-lane ports we can accept the lane number as an argument like:
> 
> ethtool --phy-test eth1 lane 0 tx-prbs prbs7
> ethtool --phy-test eth2 lane 0 rx-prbs prbs7
> 
> We referred to "Lee Trager's" "Open-Source Tooling for PHY Management and Testing" session:
> https://netdevconf.info/0x19/sessions/talk/open-source-tooling-for-phy-management-and-testing.html?.
> We have been trying to reach "Lee Trager" to seek more input, latest update on the approach and understand if there is a parallel effort in active so we can collaborate.
> If you can, please help me connect with "Lee Trager" and others who expressed interest in Ethernet PRBS. We are happy to align and start implementation.
> 

You aren't going to have much luck if you are trying to reach out via
his Meta address as he has moved onto Nvidia so he is no longer working
on the fbnic driver.

As far as the work done most of it was internal and making use of
debugfs. I don't believe any of the work for fbnic began to approach
the suggested methods for upstreamming the feature as Lee had been
pulled into other efforts.

> About standardizing across other bus like PCIe and USB, I had a quick discussion with our internal designers, but I didn't observe any such SW-level config knobs interest. 
> Looks like Ethernet has clear interest and we are joining that Ethernet PRBS community too.

I think it largely depends on what your implementation looks like. The
point being made was that many of the SerDes PHYs out there are capable
of use in multiple applications. So instead of being a networking
device you would be looking at a SerDes PHY such as those in
"/drivers/phy/".

Also do you know what layer in the PHY you are injecting this PRBS at?
I would be curious if this is PCS or at the PMD level?

If you are referring to the PCS level then yes, it would make sense to
have it in the networking subsystem as the PCS at this point is more a
netdev specific set of drivers, see "/drivers/net/pcs/".

In the case of the PMD that is where things get a bit more interesting.
There is an IEEE c45 register definition that includes PRBS testing
registers, however in the case of our implementation the PMD doesn't
follow that specification and follows more the "/drivers/phy/" model.

> Ethernet PRBS configuration and diagnostics support is well established and already widely used in existing Ethernet SERDES deployments.
> We think Ethernet is the most natural starting point within netdev, as it aligns with current driver practice and existing validation workflows. 

The problem is many of these parts used as an Ethernet Serdes PMD are
really a multiuse part. So for example in the case of the hardware in
FBNIC we use the same part on the Ethernet PHY as we do for the PCIe
Gen5 PHY.

The complication in our case is that both are buried behind our FW due
to the fact that both are shared between slices. However for testing
purposes and such we could look at disabling the odd slices to
essentially unshare the hardware if you need another platform to test
something like this with.