Received-SPF: pass (google.com: domain of linux-kernel+bounces-102683-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
References: <20240223192658.45893-1-rrameshbabu@nvidia.com>
 <20240309084440.299358-1-rrameshbabu@nvidia.com>
 <20240309084440.299358-2-rrameshbabu@nvidia.com>
 <20240312165346.14ec1941@kernel.org> <87le6lbqsa.fsf@nvidia.com>
 <20240313174107.68ca4ff1@kernel.org>
User-agent: mu4e 1.10.8; emacs 28.2
From: Rahul Rameshbabu <rrameshbabu@nvidia.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: ahmed.zaki@intel.com, aleksander.lobakin@intel.com,
 alexandre.torgue@foss.st.com, andrew@lunn.ch, corbet@lwn.net,
 davem@davemloft.net, dtatulea@nvidia.com, edumazet@google.com,
 gal@nvidia.com, hkallweit1@gmail.com, jacob.e.keller@intel.com,
 jiri@resnulli.us, joabreu@synopsys.com, justinstitt@google.com,
 kory.maincent@bootlin.com, leon@kernel.org, linux-doc@vger.kernel.org,
 linux-kernel@vger.kernel.org, liuhangbin@gmail.com,
 maxime.chevallier@bootlin.com, netdev@vger.kernel.org, pabeni@redhat.com,
 paul.greenwalt@intel.com, przemyslaw.kitszel@intel.com,
 rdunlap@infradead.org, richardcochran@gmail.com, saeed@kernel.org,
 tariqt@nvidia.com, vadim.fedorenko@linux.dev, vladimir.oltean@nxp.com,
 wojciech.drewek@intel.com
Subject: Re: [PATCH RFC v2 1/6] ethtool: add interface to read Tx hardware
 timestamping statistics
Date: Wed, 13 Mar 2024 17:50:39 -0700
In-reply-to: <20240313174107.68ca4ff1@kernel.org>
Message-ID: <87h6h9bpm1.fsf@nvidia.com>
Content-Type: text/plain
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?eo61tvK2Zmtq6pVkeVeV5p/T7tN9q+3NhK4jmQoC0ZqK8aY24r7WwJrxEYi5?=
 =?us-ascii?Q?wEsGVJqEUHUfA8eb6NW5dF2mFrmZ2yetAPGmoGKe2WMP5gn81BAtoQrk44AL?=
 =?us-ascii?Q?pomwElONdtRrK5mU8xwyrAI4PouWZ9LzykC0Ox0c80byXNAjZU9prtJD3QRR?=
 =?us-ascii?Q?EO/JOOXwfaF7/wevinvTCoOb4qvi12CI1eG/dAl7Z1eEXdzcTV1JsRPGK+GO?=
 =?us-ascii?Q?w1l7QHijMKjpR05SB/RCvXHfhH8Y4HNLgmcmt2SuXQmqMLh84P7c3hgsEfZK?=
 =?us-ascii?Q?oJZ5mb9wbIlEdKxSGD2trbQ1ABm1ivkI+KYTbsAWzQMmDpzQW6o5EFCq+28s?=
 =?us-ascii?Q?7okbdvt7wQ6TkgtCmQ1SPek/JcdiK4YVX9zm5ruSv237u1Dd/Xo6a/NayhTx?=
 =?us-ascii?Q?yOcyK2sXHoA55KedvYmP66a1Whw02y/DMDME8ACjOeqJ3/sZ0M40npsyjHgs?=
 =?us-ascii?Q?iMTSQc9Eczk0Xt2S53Yp69brrNLRAvFf9ElF8AvVoVDA6ILAHZ0/EX8Ldh8R?=
 =?us-ascii?Q?Hv+fTQ8Ixv+S2uN/svF7iOmLbteaiqy5cELEyAy7OMF4swzgDKF1IhKaeD2Z?=
 =?us-ascii?Q?66NbEM0Rf3D7uD4g4FGfKIBrbRkdSllBqPD2PHvoksQ1kGLJR6kM8qs/5NHv?=
 =?us-ascii?Q?hxBv8d0yhaePbX+nJtUxnc59ksXT3N5zY/qM7GWR9amr7kzXlKcsrRgAAecH?=
 =?us-ascii?Q?SqPhO+p4b7iPjmQz0C33NYwgYJAHxo6v7N+lqJpoA/m0tzA0DLoMbjHXJMa5?=
 =?us-ascii?Q?XNsqUejPRGv+VVEUCfS7oaAFJnFcaOGRsLBBwftI23CT9oyclaTMFhBxldM2?=
 =?us-ascii?Q?RxqdadGZ3CjO/NMyKH0cQZctHXIjW2utsQA/5rIWeDMKp9Nea23sM10tKSE4?=
 =?us-ascii?Q?4Xp57QLXHlj4fbxkoEtJ1ECJHkclqSb2AduJtiHuICIMBjvIg0f2bAnC74M1?=
 =?us-ascii?Q?1RbR+sGpealkQDkadPGGMGQ+L6vP/J/Y3C+d2DcpG5EaIFj2av+NoFNOvUjs?=
 =?us-ascii?Q?VVj18/pKv/kXyqJSfIjWt9MYxo00CVVpY6atkrVqU/05XxmYIen1Gr75aCnJ?=
 =?us-ascii?Q?y+JJ0YrpyC1WSrBgEY7a6q2XZ+vGXWZkq0SSRaIlQPgEs23arRFgyTx93Q/h?=
 =?us-ascii?Q?ORw9FAGRAifiLXw3YHCmmUl6OkwibKSjNn0jeRBhlVhGVKZ7OCjZfh8q1ryq?=
 =?us-ascii?Q?Ao22Yw+yq6etZaqYT7GSWyTsSwkkvHLOYkMeM1+FaT48GIISBFxSy8gVVxFY?=
 =?us-ascii?Q?NJX93uTo/dyXa/LhCiWKtWG+lBmdw7ALeLJPUB1A6hkSyEvhzRQDaRu7qYeD?=
 =?us-ascii?Q?uQN0nYXAUpV0gqkRn7KHN0fV79ynFZIAfiGJjvl3JtwyUbgogtku6DgDcxvJ?=
 =?us-ascii?Q?1pRsWodpoJPXy686dXKqeRlZski51qikqpk53bDg9ohCO05MiuINJK9C8G4N?=
 =?us-ascii?Q?nFx32e5eroPOdE5WE3ATyM6NGfRM1bLiqe03FBr1l7UYKvRxqilxM4NPS7WH?=
 =?us-ascii?Q?ceVRat8iOYrRYICoM64/cPrEHzDl1ydr5U/8bJ4vlSPVfhSi5qdzpC6eKLM6?=
 =?us-ascii?Q?cRyoztl5L4Y+kLU+xHBU6NccOhDdhI4p+u2j3EKAQPidZ+rSF3hZAFcPkOfH?=
 =?us-ascii?Q?og=3D=3D?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0e64e081-3cf3-43da-337c-08dc43c1326c
X-MS-Exchange-CrossTenant-AuthSource: BYAPR12MB2743.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Mar 2024 00:53:43.4617
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: pEcZuc2IwCILjTYEPQJkeCqH3GqKidU/9BZK4Ezo7MBEAwy/cLOaqzVP8KuCO3ddZ3wMjrIZ04bqa7NyddJk5g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB7001


On Wed, 13 Mar, 2024 17:41:07 -0700 Jakub Kicinski <kuba@kernel.org> wrote:
> On Wed, 13 Mar 2024 17:26:11 -0700 Rahul Rameshbabu wrote:
>> Makes sense given that these are stale and should have been changed
>> between my v1 and v2. Here is my new attempt at this.
>> 
>>  /**
>>   * struct ethtool_ts_stats - HW timestamping statistics
>>   * @tx_stats: struct group for TX HW timestamping
>>   *	@pkts: Number of packets successfully timestamped by the hardware.
>>   *	@lost: Number of hardware timestamping requests where the timestamping
>>   *            information from the hardware never arrived for submission with
>>   *            the skb.
>
> Should we give some guidance to drivers which "ignore" time stamping
> requests if they used up all the "slots"? Even if just temporary until
> they are fixed? Maybe we can add after all the fields something like:
>
>   For drivers which ignore further timestamping requests when there are
>   too many in flight, the ignored requests are currently not counted by
>   any of the statistics.

I was actually thinking it would be better to merge them into the error
counter temporarily. Reason being is that in the case Intel notices that
their slots are full, they just drop traffic from my understanding
today. If the error counters increment in that situation, it helps with
the debug to a degree. EBUSY is an error in general.

>
> Adjust as needed, I basing this on the vague memory that this was 
> the conclusion in the last discussion :)
>
>>   *	@err: Number of arbitrary timestamp generation error events that the
>>   *           hardware encountered.
>>   */
>
> Just to be crystal clear let's also call out that @lost is not included
> in @err.

Ack.

--
Thanks,

Rahul Rameshbabu