Re: Ethtool : PRBS feature

On Thu, Jul 9, 2026 at 7:37 AM Andrew Lunn [off-list ref] wrote:

On Wed, Jul 08, 2026 at 05:58:52PM -0700, Lee Trager wrote:

quoted

On 7/7/26 2:06 AM, Das, Shubham wrote:

quoted

Thanks Andrew, Lee for the feedback.

Lee,
I don't see prbs11.0, prbs11.1, prbs11.2, prbs11.3, prbs13.0, prbs13.1, prbs13.2, prbs13.3, prbs16 and prbs32 in IEEE 802.3 2022 standard.
Is this specific to fnic based on base PRBS pattern or it is mentioned in some other standard ?

Those were from the fbnic spec, I'm not sure where they originate from. I
suppose we can drop those for now but its good to keep in mind more tests
may be added in the future.

Can you find out what they actually do. It might be something as silly
as, the .1 indicate it only runs on lane 1? So these are in fact
standard prbs11 and being able to specify the lane via another
attribute is sufficient?

Looks like they are different derivations of the polynomial for the
given pattern. For example PRBS11 is 1 + x^9 + x^11, but PRBS11_0 is 1
+ x^5 + x^6 + X^10 + x^11. That is one thing to think about. When we
say PRBS7 the assumption is we are all talking about 1 + x^6 + x^7 for
the polynomial. We may want to have that clearly recorded somewhere so
there isn't any confusion on which polynomials we are using for this
testing as there is always a risk that somebody is playing with
bleeding edge hardware and ends up defining a PRBS polynomial
differently than what is expected. I almost wonder if we couldn't
define the sequence as a bitmap instead of an enum with each bit
representing which fields are in the sequence.

The 13_X values seem to be used to generate QPRBS13. I would assume
the 11_X values are something similar. Odds are they aren't in the
standard. The comphy we use supports both PCIe and SATA use cases as
well as Ethernet so it has support for additional testing that may not
be referred to in the standard. In the case of QPRBS13 it looks like
it was rejected as a testing sequence for 400G so it may not be
something that we have to concern ourselves with, at least when it
comes to testing Ethernet PHYs.