Thread (10 messages) read the whole thread 10 messages, 4 authors, 1d ago

RE: Ethtool : PRBS feature

From: Das, Shubham <hidden>
Date: 2026-07-27 18:37:52

Possibly related (same subject, not in this thread)

How does this deal with lanes or cases where you have multiple PHYs in parallel
such as the DSA setups?
We already have a lane parameter for selecting parallel lanes within a given block.

Could you elaborate on the DSA/multiple PHYs in parallel case you're referring to? 
My understanding is that (netdev, block, lane) should uniquely identify a test point.
If there are topologies where a single netdev can expose multiple instances of the
same block, then we would likely need an additional instance parameter to uniquely
identify the target block instance.
These test patterns are going to be the biggest problem with this approach. I
almost wonder if we shouldn't look at having essentially 2 sets. One for the
standard prbs values, and then one set of strings that work sort of like the private
flags where you can just specify your own string to identify it and add it as a one-
off until it can become standardized.
Thanks for the feedback. Just to clarify, the patterns listed above are not custom
or vendor-specific—they are all standard IEEE-defined test patterns. 
 
The proposal is to expose those standardized patterns only. PRBS patterns can be
used with a checker, while the remaining IEEE-defined patterns (square, scrambled idle,
TX linearity, K28.5, K28.7, etc.) are TX-only.

If there's a future need to expose vendor-specific or custom patterns, we can
certainly consider a separate mechanism, similar to private flags. 
 
For now, I think starting with the IEEE-defined patterns is a good baseline,
and we can extend it later based on additional use case.

- Shubham
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help