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

[Keller, Jacob E]

> -----Original Message-----
> From: Jakub Kicinski <kuba@xxxxxxxxxx>
> Sent: Wednesday, March 13, 2024 6:40 PM
> To: Rahul Rameshbabu <rrameshbabu@xxxxxxxxxx>
> Cc: Zaki, Ahmed <ahmed.zaki@xxxxxxxxx>; Lobakin, Aleksander
> <aleksander.lobakin@xxxxxxxxx>; alexandre.torgue@xxxxxxxxxxx;
> andrew@xxxxxxx; corbet@xxxxxxx; davem@xxxxxxxxxxxxx; dtatulea@xxxxxxxxxx;
> edumazet@xxxxxxxxxx; gal@xxxxxxxxxx; hkallweit1@xxxxxxxxx; Keller, Jacob E
> <jacob.e.keller@xxxxxxxxx>; jiri@xxxxxxxxxxx; joabreu@xxxxxxxxxxxx;
> justinstitt@xxxxxxxxxx; kory.maincent@xxxxxxxxxxx; leon@xxxxxxxxxx; linux-
> doc@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; liuhangbin@xxxxxxxxx;
> maxime.chevallier@xxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx; pabeni@xxxxxxxxxx;
> Greenwalt, Paul <paul.greenwalt@xxxxxxxxx>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@xxxxxxxxx>; rdunlap@xxxxxxxxxxxxx;
> richardcochran@xxxxxxxxx; saeed@xxxxxxxxxx; tariqt@xxxxxxxxxx;
> vadim.fedorenko@xxxxxxxxx; vladimir.oltean@xxxxxxx; Drewek, Wojciech
> <wojciech.drewek@xxxxxxxxx>
> 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.