From: Tariq Toukan <ttoukan.linux@gmail.com>
To: Kenta Akagi <k@mgml.me>,
saeedm@nvidia.com, tariqt@nvidia.com, mbloch@nvidia.com,
leon@kernel.org, andrew+netdev@lunn.ch, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com
Cc: netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC mlx5-next 0/1] net/mlx5e: Expose physical received bits counters to ethtool
Date: Wed, 28 Jan 2026 09:14:56 +0200 [thread overview]
Message-ID: <ba9b732c-7c83-4837-9310-02b6a133169f@gmail.com> (raw)
In-Reply-To: <0106019bb70737d5-06bcc3e0-d534-4e42-b8a3-71dc3b53f318-000000@ap-northeast-1.amazonses.com>
On 13/01/2026 13:04, Kenta Akagi wrote:
> On 2026/01/13 15:43, Tariq Toukan wrote:
>>
>>
>> On 13/01/2026 8:31, Tariq Toukan wrote:
>>>
>>>
>>> On 12/01/2026 9:03, Kenta Akagi wrote:
>>>> Hi,
>>>>
>>>> I would like to measure the cable BER on ConnectX.
>>>>
>>>> According to the documentation[1][2], there are counters that can be used
>>>> for this purpose: rx_corrected_bits_phy, rx_pcs_symbol_err_phy and
>>>> rx_bits_phy. However, rx_bits_phy does not show up in ethtool
>>>> statistics.
>>>>
>>>> This patch exposes the PPCNT phy_received_bits as rx_bits_phy.
>>>>
>>>>
>>>> On a ConnectX-5 with 25Gbase connection, it works as expected.
>>>>
>>>> On the other hand, although I have not verified it, in an 800Gbps
>>>> environment rx_bits_phy would likely overflow after about 124 days.
>>>> Since I cannot judge whether this is acceptable, I am posting this as an
>>>> RFC first.
>>>>
>>>
>>> Hi,
>>>
>>> This is a 64-bits counter so no overflow is expected.
>>>
>>
>> Sorry, ignore my comment, your numbers make sense.
>> Maybe it's ~248 days, but same idea.
>>
>
> Hi, thank you for checking.
>
> Ah, it seems I didn't realize it was unsigned, and I also forgot to
> include the expression. Sorry about that.
> Yes - at 800 Gbps, 0xFFFFFFFFFFFFFFFF / (800 * (2^30) * 86400) = 248.55 days,
> so it will overflow.
>
> In practice, is it possible to expose this as a statistic via ethtool?
> Or is there some other value that could be exposed for BER calculation - e.g.,
> a register that indicates the elapsed seconds since link-up?
>
> Thanks.
>
Hi Kenta,
You will find "FEC histogram" feature useful.
It splits the errors into ranges (bins), and plots a counter for each bin.
There's also a bin for 0-errors, which is what you're looking for.
Example output:
# ./tools/net/ynl/pyynl/cli.py --spec
Documentation/netlink/specs/ethtool.yaml --do fec-get --json
'{"header":{"dev-index": 5, "flags": 4}}'
{'active': 50,
'auto': 1,
'header': {'dev-index': 5, 'dev-name': 'eth3'},
'modes': {'bits': {}, 'nomask': True, 'size': 125},
'stats': {'corr-bits': [2810],
'corrected': [2123],
'hist': [{'bin-high': 0, 'bin-low': 0, 'bin-val': 235826196705},
{'bin-high': 1, 'bin-low': 1, 'bin-val': 1436},
{'bin-high': 2, 'bin-low': 2, 'bin-val': 687},
{'bin-high': 3, 'bin-low': 3, 'bin-val': 0},
{'bin-high': 4, 'bin-low': 4, 'bin-val': 0},
{'bin-high': 5, 'bin-low': 5, 'bin-val': 0},
{'bin-high': 6, 'bin-low': 6, 'bin-val': 0},
{'bin-high': 7, 'bin-low': 7, 'bin-val': 0},
{'bin-high': 8, 'bin-low': 8, 'bin-val': 0},
{'bin-high': 9, 'bin-low': 9, 'bin-val': 0},
{'bin-high': 10, 'bin-low': 10, 'bin-val': 0},
{'bin-high': 11, 'bin-low': 11, 'bin-val': 0},
{'bin-high': 12, 'bin-low': 12, 'bin-val': 0},
{'bin-high': 13, 'bin-low': 13, 'bin-val': 0},
{'bin-high': 14, 'bin-low': 14, 'bin-val': 0},
{'bin-high': 15, 'bin-low': 15, 'bin-val': 0}],
'uncorr': [0]}}
prev parent reply other threads:[~2026-01-28 7:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-12 7:03 Kenta Akagi
2026-01-12 7:03 ` [PATCH RFC mlx5-next 1/1] " Kenta Akagi
2026-01-13 6:31 ` [PATCH RFC mlx5-next 0/1] " Tariq Toukan
2026-01-13 6:43 ` Tariq Toukan
2026-01-13 11:04 ` Kenta Akagi
2026-01-28 7:14 ` Tariq Toukan [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ba9b732c-7c83-4837-9310-02b6a133169f@gmail.com \
--to=ttoukan.linux@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=k@mgml.me \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mbloch@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeedm@nvidia.com \
--cc=tariqt@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®