On Fri Aug 22 2025, Sebastian Andrzej Siewior wrote: > On 2025-08-22 09:28:10 [+0200], Kurt Kanzenbach wrote: >> The current implementation uses schedule_work() which is executed by the >> system work queue to retrieve Tx timestamps. This increases latency and can >> lead to timeouts in case of heavy system load. >> >> Therefore, switch to the PTP aux worker which can be prioritized and pinned >> according to use case. Tested on Intel i210. >> >> Signed-off-by: Kurt Kanzenbach <[email protected]> >> --- >> Changes in v2: >> - Switch from IRQ to PTP aux worker due to NTP performance regression >> (Miroslav) >> - Link to v1: >> https://lore.kernel.org/r/[email protected] > > For the i210 it makes sense to read it directly from IRQ avoiding the > context switch and the delay resulting for it. For the e1000_82576 it > makes sense to avoid the system workqueue and use a dedicated thread > which is not CPU bound and could prioritized/ isolated further if > needed. > I don't understand *why* reading the TS in IRQ is causing this packet > loss.
Me neither. I thought it could be the irqoff time. On my test systems
the TS IRQ takes about ~16us with reading the timestamp. In the
kworker/ptp aux thread scenario it takes about ~6us IRQ time + ~10us run
time for the threads. All of that looks reasonable to me.
Also I couldn't really see a performance degradation with ntpperf. In my
tests the IRQ variant reached an equal or higher rate. But sometimes I
get 'Could not send requests at rate X'. No idea what that means.
Anyway, this patch is basically a compromise. It works for Miroslav and
my use case.
> This is also what the igc does and the performance improved
> afa141583d827 ("igc: Retrieve TX timestamp during interrupt handling")
>
> and here it causes the opposite?
As said above, I'm out of ideas here.
Thanks,
Kurt
signature.asc
Description: PGP signature
