Re: [PATCH iwl-next v2] igb: Convert Tx timestamping to PTP aux worker

[Jacob Keller <jacob.e.keller@intel.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1799 bytes --]



On 8/22/2025 12:52 AM, 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 <kurt@linutronix.de>
>> ---
>> Changes in v2:
>> - Switch from IRQ to PTP aux worker due to NTP performance regression (Miroslav)
>> - Link to v1: https://lore.kernel.org/r/20250815-igb_irq_ts-v1-1-8c6fc0353422@linutronix.de
> 
> 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. 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?
> 
> Sebastian

Miroslav reported a test using ntpperf which showed a pretty significant
impact for higher rates. It was indeed better for low rates, but was
much worse for high rates.

See the following:

https://lore.kernel.org/all/aKMbekefL4mJ23kW@localhost/

In all cases the use of the thread was better, so this improves the
behavior without regressing in the case of many more packets.

It is unclear exactly why the ntpperf test fails so badly in that case
with the higher rate for i210.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]