[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87bkbtpjck.fsf@nvidia.com>
Date: Thu, 16 Nov 2023 11:51:39 -0800
From: Rahul Rameshbabu <rrameshbabu@...dia.com>
To: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
Cc: Saeed Mahameed <saeed@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Eric Dumazet <edumazet@...gle.com>,
Saeed Mahameed <saeedm@...dia.com>, netdev@...r.kernel.org,
Tariq Toukan <tariqt@...dia.com>, Gal Pressman <gal@...dia.com>
Subject: Re: [net-next 08/14] net/mlx5e: Introduce lost_cqe statistic
counter for PTP Tx port timestamping CQ
On Tue, 14 Nov, 2023 10:22:43 -0500 Vadim Fedorenko <vadim.fedorenko@...ux.dev> wrote:
> On 13/11/2023 15:00, Saeed Mahameed wrote:
>> From: Rahul Rameshbabu <rrameshbabu@...dia.com>
>> Track the number of times the a CQE was expected to not be delivered on PTP
>> Tx port timestamping CQ. A CQE is expected to not be delivered of a certain
>> amount of time passes since the corresponding CQE containing the DMA
>> timestamp information has arrived. Increment the late_cqe counter when such
>> a CQE does manage to be delivered to the CQ.
>>
>
> It looks like missed/late timestamps is common problem for NICs. What do
> you think about creating common counters in ethtool to have general
> interface to provide timestamps counters? It may simplify things a lot.
Hi Vadim,
I just took a look at the tree and believe devices supported by the
following drivers have missed/late timestamps.
- mlx5
- i40e
- ice
- stmicro
The above is from a very precursory grep through the netdev tree and
maybe inaccurate/incomplete.
You probably saw that Saeed already pulled out our vendor specific stat
counters from his v2 submission. Lets discuss the more appropriate
common counters in ethtool.
Similar to fec-stat in Documentation/netlink/specs/ethtool.yaml, should
we make a new statistics group for these timestamp related counters
(timestamp-stat) as follows?
1. Implement an ethtool_timestamp_stats struct in ethtool.h
2. Add the relevant callback support in ethtool
3. Add the correct spec changes in the ynl spec.
4. Implement the callback in the appropriate drivers
5. Separately prepare relevant userspace changes for ethtool.
If this seems reasonable, I can start preparing an RFC to send out to
the mailing list.
--
Thanks,
Rahul Rameshbabu
Powered by blists - more mailing lists