Re: Ethtool : PRBS feature

Hi Andrew,
I think there is a disconnect here. Please see the diagram attached indicating the error injection location.
Here, we are referring to error injection at the "bit" level, not "frame" level.
Bit error(s) injected at the PMA/PMD boundary, does not distinguish between data (Frames) vs test patterns (PRBS).
Many SerDes IP's , if not all, include error injection as part of the test pattern block (BIST in the diagram).
Some IP's may have error injection outside of BIST in the common data path (as shown in the diagram) in which case bit errors may be injected in both data mode (frame/traffic) and test pattern mode (BIST).
Regardless, we are seeking error injection capability at PMA/PMD to be made available through user/driver space (ethtool) .

Notes:

  1.
Error injection can be "one-shot" (single error) or continuous (fixed rate, say 1 bit error every 10**6 bits (1E-6)).
  2.
Error injection availability is IP/API dependent. One-shot mode is highly likely to be available in all SerDes IP's.
  3.
Error injection location and implementation is IP dependent.
  4.
If IP/API supported:
     *
One-shot error injected in test pattern (PRBS) mode captured as individual/single bit error at the far-end checker.
     *
One-shot error injected in data (traffic/frame) mode captured as:
        *
Individual/single corrected codeword error if FEC is used for the link
        *
Individual/single CRC:  (a) if FEC is not used for the link and (b) if bit error injected corrupts any of the bits used to compute CRC.
     *
Effect of errors injected at fixed rate is a corollary to one-shot with additional :
        *
Errors injected at higher rates (> 1E-4) may result in uncorrected FEC codewords or loss of link
        *
Presence of uncorrected FEC codewords will lead to MAC CRCs

What is requested:

  1.
One-shot bit error injection (required/preferred), fixed rate is optional

How to inject error:

  1.
Test pattern mode:
     *
Generate any PRBS pattern
     *
Configure error checker on receive side (same device in loopback mode or far-end device) - measure Bit Error Ratio (BER) without error injection
     *
Inject error and verify BER>0 (if BER==0 without injection)
  2.
Data (Traffic/Frame) mode:
     *
Configure and establish link (same device in loopback mode or far-end device)
     *
Measure MAC CRC and/or FEC corrected/uncorrected codeword counts
     *
Inject error and verify MAC CRC or FEC corrected counts match injected error count



Vijay

________________________________
From: Andrew Lunn <andrew@lunn.ch>
Sent: Wednesday, July 1, 2026 10:32 AM
To: Das, Shubham <redacted>
Cc: Alexander Duyck <redacted>; Lee Trager <redacted>; Maxime Chevallier <maxime.chevallier@bootlin.com>; netdev@vger.kernel.org <redacted>; mkubecek@suse.cz <redacted>; D H, Siddaraju <redacted>; Chintalapalle, Balaji <redacted>; Lindberg, Magnus <redacted>; niklas.damberg@ericsson.com <redacted>; Wirandi, Jonas <redacted>; Srinivasan, Vijay <redacted>
Subject: Re: Ethtool : PRBS feature

On Wed, Jul 01, 2026 at 05:10:43PM +0000, Das, Shubham wrote:

quoted

Sorry, but i could not implement that, in a sensible way, given its current
specification.

I suppose i could simply flip the first `inject-error-count` bits, and make the rest of
the stream perfect? I could also wait until the stop command is received, and
then flip that many bits before i stop the stream? But none of these seem
sensible.

Please make this specification have sufficient details, or references to 802.3, that
you could give it to another engineer and get back a reasonable implementation,
without having to answer any questions.

Andrew,

IEEE has clear documentation of the PRBS Receiver block and the BER counter as an output.
Before performing the actual BER validation, it is a usual industry practice to introduce errors
to guarantee that the checker is functional and accurately identifying them.

Similarly, in DATA mode, error injection is used to verify the FEC block
by ensuring that injected errors are detected and corrected as expected.

Updated description.

+        name: inject-error-count
+        type: u32
+        doc: |
+          Request the PHY to inject exactly this many bit errors into the
+          currently active test data stream.
+
+          This is a diagnostic tool used to validate that the far-end PRBS
+          checker or FEC decoder is functioning correctly. For example,
+          after enabling a PRBS pattern and confirming ber-lock-status is
+          locked, injecting N errors should cause ber-error-count to
+          increment by exactly N on the receiving port, confirming the
+          checker is actively detecting bit errors. Similarly, in normal
+          data mode with FEC enabled, injecting errors verifies that the
+          FEC block detects errors as expected.

There is no mention of how many frames to send in the stream. I don't
think that is part of the API? Because we have no idea of how many
frames will be sent, it is not possible to distribute the corrupted
frames over the duration of the stream. So that means i should flip
one bit, anywhere in the first inject-error-count frames. All frames
after that should not have bit flips. The assumption being, the stream
has a minimum of inject-error-count frames, and if the stream is
short, the counter will be too low. But it does not matter if the
stream is longer.

Your description has no mention of frames. Should it? What exactly
does the ber-error-count count? Can multiple bit flip within one frame
be counted individually? I don't see how, since the checksum just says
the frame is bad, and cannot report how bad.

As i said, give this description to another engineer and ask him/her
how it could be implemented.

https://www.youtube.com/watch?v=j-6N3bLgYyQ

        Andrew