From: netdev-bot+sashiko@kernel.org
To: tariqt@nvidia.com
Cc: andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, netdev@vger.kernel.org, pabeni@redhat.com,
cjubran@nvidia.com, dtatulea@nvidia.com, gal@nvidia.com,
leon@kernel.org, linux-kernel@vger.kernel.org,
linux-rdma@vger.kernel.org, mbloch@nvidia.com,
rrameshbabu@nvidia.com, richardcochran@gmail.com,
saeedm@nvidia.com, shshitrit@nvidia.com
Subject: Re: [PATCH net] net/mlx5e: Keep HW timestamp stats monotonic across reconfiguration
Date: Sun, 06 Sep 2026 19:00:42 +0000 [thread overview]
Message-ID: <178872124291.219967.5690857105577484083@kernel.org> (raw)
In-Reply-To: <20260902193731.3668958-1-tariqt@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider:
Critical: 0 · High: 0 · Medium: 1 (1) · Low: 0
- [Medium] mlx5e_stats_ts_get()
(drivers/net/ethernet/mellanox/mlx5/core/en_stats.c:1199-1236)…
Pre-existing issues:
- [Medium] The mlx5 PTP CQ -> struct ethtool_ts_stats mapping retained
(and re-indented) by this patch in mlx5e_stats_ts_get()…
--
net/mlx5e: Keep HW timestamp stats monotonic across reconfiguration
mlx5e_stats_ts_get() no longer picks between DMA and port timestamp
counters based on tx_ptp_opened, and instead always sums the DMA
timestamp counters from the persistent per-channel statistics, adding the
port timestamp counters once the PTP TX queues have been opened. The
state_lock is dropped since only persistent stats are read now.
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_stats.c b/drivers/net/ethernet/mellanox/mlx5/core/en_stats.c
> index e7e6db7f6bf1..cd94bb44f6ab 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_stats.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_stats.c
> @@ -1199,50 +1199,39 @@ void mlx5e_stats_rmon_get(struct mlx5e_priv *priv,
> void mlx5e_stats_ts_get(struct mlx5e_priv *priv,
> struct ethtool_ts_stats *ts_stats)
> {
> - int i, j;
> + u16 nch = mlx5e_stats_nch_read(priv);
> + int i, tc;
>
> - mutex_lock(&priv->state_lock);
> + ts_stats->pkts = 0;
>
> - if (priv->tx_ptp_opened) {
> - struct mlx5e_ptp *ptp = priv->channels.ptp;
> + for (i = 0; i < nch; i++) {
> + struct mlx5e_channel_stats *channel_stats =
> + priv->channel_stats[i];
>
> - ts_stats->pkts = 0;
> + for (tc = 0; tc < priv->max_opened_tc; tc++)
> + ts_stats->pkts += channel_stats->sq[tc].timestamps;
> + }
[Severity: Medium]
Does this loop miss the HTB/QoS send queue timestamp counters?
The DMA accumulation here only walks priv->channel_stats[i]->sq[tc], but
HTB offload SQs keep their statistics elsewhere, in
mlx5e_open_qos_sq():
drivers/net/ethernet/mellanox/mlx5/core/en/qos.c:mlx5e_open_qos_sq() {
...
err = mlx5e_open_txqsq(c, tisn, txq_ix, params, ¶m_sq, sq, 0, hw_id,
priv->htb_qos_sq_stats[node_qid]);
...
}
Those SQs are opened without a ptpsq (sq->ptpsq is only assigned in
mlx5e_ptp_open_txqsq()), so every hardware timestamped skb completing on
an HTB class queue takes the DMA branch:
drivers/net/ethernet/mellanox/mlx5/core/en_tx.c:mlx5e_consume_skb() {
...
} else {
skb_tstamp_tx(skb, &hwts);
sq->stats->timestamps++;
}
...
}
incrementing priv->htb_qos_sq_stats[qid]->timestamps, which the new code
never reads. With HTB TX offload configured, are those packets then
permanently absent from ETHTOOL_A_TS_STAT_PKTS, even though the driver
still reports the same events privately as qos_txN_timestamps via
MLX5E_DECLARE_QOS_TX_STAT(struct mlx5e_sq_stats, timestamps)?
If so, should the new comment claiming DMA timestamp counters are
accumulated also mention this queue class, or should the loop fold in
priv->htb_qos_sq_stats[] as well?
> +
> + /* Accumulate DMA and port timestamp counters so values stay monotonic
> + * across channel teardown and mode switches.
> + */
> + if (priv->tx_ptp_opened) {
> + /* Err and Lost stats are only relevant for port timestamping,
> + * as the DMA layer will always successfully timestamp packets.
> + */
> ts_stats->err = 0;
> ts_stats->lost = 0;
>
> - if (!ptp)
> - goto out;
> -
> - /* Aggregate stats across all TCs */
> - for (i = 0; i < ptp->num_tc; i++) {
> + for (tc = 0; tc < priv->max_opened_tc; tc++) {
> struct mlx5e_ptp_cq_stats *stats =
> - ptp->ptpsq[i].cq_stats;
> + &priv->ptp_stats.cq[tc];
>
> ts_stats->pkts += stats->cqe;
> ts_stats->err += stats->abort + stats->err_cqe +
> - stats->late_cqe;
> + stats->late_cqe;
> ts_stats->lost += stats->lost_cqe;
> }
[Severity: Medium]
This is a pre-existing mapping that this patch only re-indents, so it is
not introduced here, but can the same timestamp request end up counted in
pkts, lost and err at once?
The kernel-doc for struct ethtool_ts_stats in include/linux/ethtool.h
describes err as:
* @err: Number of arbitrary timestamp generation error events that the
* hardware encountered, exclusive of @lost statistics.
In the driver, a request whose port CQE has not arrived within the
undelivered timeout bumps lost_cqe while the skb stays in the metadata
map:
drivers/net/ethernet/mellanox/mlx5/core/en/ptp.c:mlx5e_ptpsq_mark_ts_cqes_undelivered() {
...
ptpsq->cq_stats->lost_cqe++;
...
}
If that CQE arrives later, mlx5e_ptp_handle_ts_cqe() takes the
!nodes[metadata_id].inuse path and bumps late_cqe (mapped to err), and
for a non-error CQE also cqe (mapped to pkts).
Similarly, an aborted timestamp never reaches skb_tstamp_tx():
drivers/net/ethernet/mellanox/mlx5/core/en/ptp.c:mlx5e_skb_cb_hwtstamp_tx() {
...
ptpsq->cq_stats->abort++;
ptpsq->cq_stats->abort_abs_diff_ns += diff;
...
return;
}
yet cq_stats->cqe was already incremented for that CQE, so pkts counts a
packet whose timestamp was never delivered to the socket while err counts
it too.
Since this patch turns pkts into a permanent DMA plus port sum, would it
be worth documenting or correcting the overlap so userspace summing
pkts/lost/err does not exceed the number of timestamp requests?
> }
> -
> -out:
> - mutex_unlock(&priv->state_lock);
> }
[ ... ]
--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260902193731.3668958-1-tariqt%40nvidia.com
prev parent reply other threads:[~2026-09-06 19:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 19:37 [PATCH net] net/mlx5e: Keep HW timestamp stats monotonic across reconfiguration Tariq Toukan
2026-09-05 20:30 ` patchwork-bot+netdevbpf
2026-09-06 19:00 ` netdev-bot+sashiko [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=178872124291.219967.5690857105577484083@kernel.org \
--to=netdev-bot+sashiko@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=cjubran@nvidia.com \
--cc=davem@davemloft.net \
--cc=dtatulea@nvidia.com \
--cc=edumazet@google.com \
--cc=gal@nvidia.com \
--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=richardcochran@gmail.com \
--cc=rrameshbabu@nvidia.com \
--cc=saeedm@nvidia.com \
--cc=shshitrit@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