On Thu, 14 Mar, 2024 17:50:10 +0000 "Keller, Jacob E" <jacob.e.keller@xxxxxxxxx> wrote: >> -----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. 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
