Dear Martin, On Tue, Feb 20, 2024 at 2:17PM +0100, Martin Kulas wrote: [...] > > > > > > When searching for a solution about this high latency TX timestamp read, > > > I found the following thread from 2022: > > > > > > https://patchwork.ozlabs.org/project/intel-wired-lan/patch/[email protected]/#2963591 > > > > > > Is this patch already in the current Linux Kernel 6.7.4 or is it pending? > > > > In the metadata on the patchwork page it says *Accepted*, and it seems to be > > commit 1229b33973c7 (ice: Add low latency Tx timestamp read) added to Linux > > 6.1-rc1, so it should be in Linux 6.1. > > > > Please build the Linux kernel from this commit to rule out any regression. > > (If that commit actually should support such low times that you require. The > > commit message says something about 20 ms before.) > > After having applied that commit, the TX timestamp read latency stays > unacceptable high (in the range of about 700 microseconds), i.e. no > regression.
This improvement utilises 'low latency read', where the driver writes a timestamp request to a specific register, FW has to poll this register every 0.6 ms and then the driver receives a second interrupt, so that it can read the timestamp from this register. Unfortunately, polling every 0.6 ms is the best we could do. [...] > With an other NIC that supports hardware TX timestamping (Intel X550), > the TX timestamp read latency is much smaller than on Intel E810-XXVDA2, > i.e. 7 microseconds. I am puzzled that an older Intel network card > provides the hardware TX timestamp about 100 times faster than > an new Intel network card. Intel X550 had a direct PHY register access. Intel E810 does not have this possibility due to HW design. Only FW can access PHY registers directly. Before low latency Tx timestamp patch, the driver used AdminQ message to get the timestamp, but it was far too slow and inconsistent. [...] Kind regards, Karol
