On Tue Feb 10 2026, Willem de Bruijn wrote: > The core issue seems to be that the ptp_tx_work is not scheduled > quickly enough. I wonder if that is the issue to be fixed. When/why > is this too slow?
The igb driver uses schedule_work() for the Tx timestamp retrieval. That means the ptp_tx_work item is queued to the kernel-global workqueue. In case there is load on the system, the kworker which handles ptp_tx_work might be delayed too much, which results in ptp4l timeouts. Easy solution would be to tune the priority/affinity of the kworker. However, we have to figure which kworker it is. Furthermore, this kworker might handle other things as well, which are not related to igb timestamping at all. Therefore, tuning the priority of the kworker is not practical. Moving the timestamping in IRQ looked like a good solution, because the device already signals that the Tx timestamp is available now. No need to schedule any worker/work at all. So, it'd be very nice if skb_tstamp_tx() could be called from IRQ context. BTW other drivers like igc call this function in IRQ context as well. Alternative solution for igb is to move from schedule_work() to PTP AUX worker. That is a dedicated PTP worker thread called ptpX, which could handle the timestamping. This can be easily tuned with taskset and chrt. However, there's one difference to the kworker approach: The kworker always runs on the same CPU, where the IRQ triggered, the AUX worker not necessarily. This means, Miroslav needs to be aware of this and tune the AUX worker for his NTP use cases. I hope, that makes the motivation for this patch and discussion clear. Thanks, Kurt
signature.asc
Description: PGP signature
