Messages in this thread | | | From | "Keller, Jacob E" <> | Subject | RE: [PATCH RFC v2 1/6] ethtool: add interface to read Tx hardware timestamping statistics | Date | Thu, 14 Mar 2024 17:50:10 +0000 |
| |
> -----Original Message----- > From: Jakub Kicinski <kuba@kernel.org> > Sent: Wednesday, March 13, 2024 6:40 PM > To: Rahul Rameshbabu <rrameshbabu@nvidia.com> > Cc: Zaki, Ahmed <ahmed.zaki@intel.com>; Lobakin, Aleksander > <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; Keller, Jacob E > <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; > Greenwalt, Paul <paul.greenwalt@intel.com>; Kitszel, Przemyslaw > <przemyslaw.kitszel@intel.com>; rdunlap@infradead.org; > richardcochran@gmail.com; saeed@kernel.org; tariqt@nvidia.com; > vadim.fedorenko@linux.dev; vladimir.oltean@nxp.com; Drewek, Wojciech > <wojciech.drewek@intel.com> > 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.
| |