RE: Ethtool : PRBS feature
From: Das, Shubham <hidden>
Date: 2026-07-07 09:06:05
Subsystem:
networking [ethtool], networking [general], the rest, yaml netlink (ynl) · Maintainers:
Andrew Lunn, Jakub Kicinski, "David S. Miller", Eric Dumazet, Paolo Abeni, Linus Torvalds, Donald Hunter
Possibly related (same subject, not in this thread)
- 2026-07-02 · Re: Ethtool : PRBS feature · Lee Trager <hidden>
- 2026-07-01 · Re: Ethtool : PRBS feature · Lee Trager <hidden>
- 2026-07-01 · Re: Ethtool : PRBS feature · Andrew Lunn <andrew@lunn.ch>
- 2026-07-01 · Re: Ethtool : PRBS feature · Srinivasan, Vijay <hidden>
- 2026-07-01 · Re: Ethtool : PRBS feature · Andrew Lunn <andrew@lunn.ch>
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 ? Each lane and each direction is a completely separate test with its own test of
statistics. The test is actually verified on the Rx side, Tx is your generator so you won't have data to collect. So when you run PRBS testing on a 2 lane NIC you are actually running 4 independent tests. While its fine to have a shortcut to run the same test on all lanes we absolutely need a way to run tests per lane and the ability to choose Rx, Tx, or both.
- Agree, we need lane parameter in commands, Updated command.
I wouldn't consider stats a phy-test action. It shouldn't change the state of the NIC at all. I would just add phy-test-stats as set of standard ethtool statistics.
Yes moved under separate command. Below are the updated UAPI, data structures, and Netlink messages to support PRBS/BERT and test pattern configuration.
diff --git a/Documentation/netlink/specs/ethtool.yaml b/Documentation/netlink/specs/ethtool.yaml
index 5e9135e3774f..113005a5f80a 100644
--- a/Documentation/netlink/specs/ethtool.yaml
+++ b/Documentation/netlink/specs/ethtool.yaml@@ -30,6 +30,35 @@ definitions: + - + name: phy-test-pattern + enum-name: phy-test-pattern + type: enum + name-prefix: phy-test-pattern- + doc: PRBS and other PHY test patterns + entries: + - off + - prbs7 + - prbs9 + - prbs11 + - prbs13 + - prbs15 + - prbs23 + - prbs31 + - ssprq + - prbs13q + - prbs31q + - square8 + name: phy-test-action + enum-name: phy-test-action + type: enum + name-prefix: phy-test-action- + doc: Actions for PHY BERT test control + entries: + - none + - start + - stop + name: phy-test + attr-cnt-name: __ethtool-a-phy-test-cnt + doc: | + PHY test configuration for pattern generation/checking, + BERT (Bit Error Rate Test), and statistics. + attributes: + - + name: unspec + type: unused + value: 0 + - + name: header + type: nest + nested-attributes: header + - + name: lane + type: u32 + doc: PHY lane index to target for the test operation + - + name: tx-pattern + type: u32 + doc: TX test pattern type (PRBS or square8 wave) + enum: phy-test-pattern + - + name: rx-pattern + type: u32 + doc: RX checker pattern type (PRBS or square8 wave) + enum: phy-test-pattern + - + name: bert-action + type: u32 + doc: BERT test start/stop + enum: phy-test-action + - + name: inject-error-count + type: u32 + doc: | + Inject a specified number of bit errors into the PHY transmit data + stream for diagnostic verification purposes. + + Context and Purpose: + When performing Bit Error Ratio Testing (BERT), the receiving side + runs a PRBS checker that monitors for bit errors. Before relying + on a zero-error BERT result, operators need to confirm Checker + state and configuration to qualify result as TRUE. + A checker that is broken or misconfigured would also report + zero errors, giving a FALSE pass. Error injection provides this + confirmation by deliberately introducing a known number of errors + on the transmit side and verifying they appear on the receive side. + + Note: + Receiver under test maybe in the same port as the transmitter + (loopback mode) or a different port in the same device or another + device connected to the transmitting port (non-loopback mode). + + Layer and Mechanism: + Error injection operates at the PMA/PMD boundary. This is + bit-level injection in the serial data stream, not frame-level. + The SerDes Built-In Self Test (BIST) block inverts the specified + number of bits in the outgoing serial stream. The injection does + not distinguish between data frames and test patterns; it + corrupts raw bits at the physical layer regardless of what the + stream carries. + + Mode of Operation: + This command implements "one-shot" injection: a single burst of + N bit errors injected immediately. The PHY inverts exactly N + consecutive bits in the serial transmit stream at the PMA/PMD + layer, then resumes clean transmission. No continuous/fixed-rate + injection mode is provided. + + Prerequisites: + - A PRBS test pattern must be active on the transmitting port + (tx-pattern != off). + - The receiving port must have the matching rx-pattern configured + and ber-lock-status must be "locked" (indicating the checker + has synchronized to the incoming pattern). + - BERT must be running on the receiving port (bert start issued). + + Note: + Availability of BIST mode test pattern generator, checker and + lock indication is IP dependent. + + Semantics: + - Fire-and-forget: the command completes immediately. No + persistent state is created. Each invocation is an independent + injection event. + - The command may be issued multiple times. Each invocation + injects an additional burst of errors (counts accumulate on + the receiver's ber-error-count across invocations). + - If no test pattern is active, the behaviour is + implementation-defined (hardware may silently ignore the + request or return an error). + + Expected Outcome: + After injecting N errors on the TX port, the far-end receiver's + ber-error-count (read via --show-phy-test) should increment by + exactly N (within hardware counter precision). This confirms: + 1. The PRBS checker is locked and actively counting errors. + 2. The data path between TX and RX is intact. + 3. The BERT counters are functioning correctly. + + Example Workflow: + # Configure TX pattern on port A + ethtool --phy-test eth1 lane 0 tx-pattern prbs31 + # Configure RX checker on port B, start BERT + ethtool --phy-test eth2 lane 0 rx-pattern prbs31 + ethtool --phy-test eth2 lane 0 bert start + # Verify lock + ethtool --show-phy-test eth2 lane 0 + # -> ber-lock-status: locked, ber-error-count: 0 + # Inject 5 errors from TX side + ethtool --phy-test eth1 lane 0 inject-errors 5 + # Confirm errors were detected + ethtool --show-phy-test eth2 lane 0 + # -> ber-error-count: 5 + - + name: ber-lock-status + type: u8 + doc: PRBS lock status (1=locked, 0=not locked) + - + name: ber-error-count + type: u64 + doc: BERT bit error count + - + name: ber-total-bits-sent + type: u64 + doc: BERT total bits sent + - + name: supported-test-patterns + type: u32 + doc: Bitmask of supported test patterns + - + name: phy-test-act + doc: | + Configure PHY test parameters. Each attribute is optional and only + specified attributes are applied. TX/RX patterns are set on the + local port. BERT and error injection operate on the receiver port. + Typical workflow: + ethtool --phy-test eth1 lane 0 tx-pattern prbs7 (TX side) + ethtool --phy-test eth2 lane 0 rx-pattern prbs7 (RX side) + ethtool --phy-test eth2 lane 0 bert start (start BERT on RX) + ethtool --phy-test eth1 lane 0 inject-errors 10 (inject 10 errors on TX) + ethtool --show-phy-test eth2 lane 0 (read counters, expect +10) + ethtool --phy-test eth2 lane 0 bert stop (stop BERT) + + attribute-set: phy-test + + do: + request: + attributes: + - header + - lane + - tx-pattern + - rx-pattern + - bert-action + - inject-error-count + - + name: phy-test-get + doc: | + Get PHY test configuration status, supported patterns, and BERT + statistics (lock status, error count, total bits). + + attribute-set: phy-test + + do: + request: + attributes: + - header + - lane + reply: + attributes: + - header + - lane + - tx-pattern + - rx-pattern + - supported-test-patterns + - ber-lock-status + - ber-error-count + - ber-total-bits-sent mcast-groups: list: - Shubham D
From: Srinivasan, Vijay <redacted> Sent: 02 July 2026 05:19 To: Lee Trager <redacted>; Andrew Lunn <andrew@lunn.ch> Cc: Das, Shubham <redacted>; Alexander Duyck <redacted>; Maxime Chevallier <maxime.chevallier@bootlin.com>; netdev@vger.kernel.org; mkubecek@suse.cz; D H, Siddaraju <redacted>; Chintalapalle, Balaji <redacted>; Lindberg, Magnus <redacted>; niklas.damberg@ericsson.com; Wirandi, Jonas <redacted> Subject: Re: Ethtool : PRBS feature All good points and noted. Will write the specification in general terms with full description of context, usage, configuration, expected outcome etc. Vijay ________________________________________ From: Lee Trager <mailto:lee@trager.us> Sent: Wednesday, July 1, 2026 4:28 PM To: Andrew Lunn <mailto:andrew@lunn.ch>; Srinivasan, Vijay <mailto:vijay.srinivasan@intel.com> Cc: Das, Shubham <mailto:shubham.das@intel.com>; Alexander Duyck <mailto:alexander.duyck@gmail.com>; Maxime Chevallier <mailto:maxime.chevallier@bootlin.com>; mailto:netdev@vger.kernel.org <mailto:netdev@vger.kernel.org>; mailto:mkubecek@suse.cz <mailto:mkubecek@suse.cz>; D H, Siddaraju <mailto:siddaraju.dh@intel.com>; Chintalapalle, Balaji <mailto:balaji.chintalapalle@intel.com>; Lindberg, Magnus <mailto:magnus.k.lindberg@ericsson.com>; mailto:niklas.damberg@ericsson.com <mailto:niklas.damberg@ericsson.com>; Wirandi, Jonas <mailto:jonas.wirandi@ericsson.com> Subject: Re: Ethtool : PRBS feature On 7/1/26 3:02 PM, Andrew Lunn wrote:
On Wed, Jul 01, 2026 at 09:38:08PM +0000, Srinivasan, Vijay wrote:quoted
Hi Andrew, I think there is a disconnect here.Which proves my point. The specification is not sufficient if you have to keep correcting me. The kAPI should be understandable by somebody who has a general networking background. Please write a specification with that assumption in mind. Don't assume the reader is a test engineer who has used PRBS for half his life. Assume it is a brand new test engineer who is hearing PRBS for the first time. That is what most engineers on the netdev list are. Me included.
I think part of the disconnect is that PRBS testing is a signal integrity test, not a network test. In this case the phy happens to be Ethernet but it could just as easily be PCIE or USB. That is why it was heavily suggested to me at netdev 0x19 that this should be done on the generic phy layer, not netdev. Lee