Subject: Re: [PATCH RFC v2 1/6] ethtool: add interface to read Tx hardware timestamping statistics

From: Rahul Rameshbabu <[email-masked]>
Date: Thu, 14 Mar 2024 11:48:11 -0700

On Thu, 14 Mar, 2024 17:50:10 +0000 "Keller, Jacob E" <[email-masked]> wrote:
>> -----Original Message-----
>> From: Jakub Kicinski <[email-masked]>
>> Sent: Wednesday, March 13, 2024 6:40 PM
>> To: Rahul Rameshbabu <[email-masked]>
>> Cc: Zaki, Ahmed <[email-masked]>; Lobakin, Aleksander
>> <[email-masked]>; [email-masked];
>> [email-masked]; [email-masked]; [email-masked]; [email-masked];
>> [email-masked]; [email-masked]; [email-masked]; Keller, Jacob E
>> <[email-masked]>; [email-masked]; [email-masked];
>> [email-masked]; [email-masked]; [email-masked]; linux-
>> [email-masked]; [email-masked]; [email-masked];
>> [email-masked]; [email-masked]; [email-masked];
>> Greenwalt, Paul <[email-masked]>; Kitszel, Przemyslaw
>> <[email-masked]>; [email-masked];
>> [email-masked]; [email-masked]; [email-masked];
>> [email-masked]; [email-masked]; Drewek, Wojciech
>> <[email-masked]>
>> Subject: Re: [PATCH RFC v2 1/6] ethtool: add interface to read Tx hardware
>> timestamping statistics
>> 
>> On Wed, 13 Mar 2024 17:50:39 -0700 Rahul Rameshbabu wrote:
>> > > 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.
>> 
>> That works, too, let's recommend it (FWIW no preference whether
>> in the entry for @err or somewhere separately in the kdoc).
>
> We don't drop traffic, we send the packets just fine.. We just never report a
> timestamp for them, since we don't program the hardware to capture that
> timestamp.

My actual kdoc comments are better now, but I should have been better
with the language I used here in the email. In my head, I was thinking
more about the case of not submitting HW timestamp information when
sending out the packet rather than dropping the packet entirely (I would
say that is still a timestamping error case).

--
Thanks,

Rahul Rameshbabu