[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87cy8ooji5.fsf@jax.kurt.home>
Date: Thu, 21 Aug 2025 16:08:02 +0200
From: Kurt Kanzenbach <kurt@...utronix.de>
To: Miroslav Lichvar <mlichvar@...hat.com>
Cc: Jacob Keller <jacob.e.keller@...el.com>, Tony Nguyen
<anthony.l.nguyen@...el.com>, Przemek Kitszel
<przemyslaw.kitszel@...el.com>, Andrew Lunn <andrew+netdev@...n.ch>,
"David S. Miller" <davem@...emloft.net>, Eric Dumazet
<edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
<pabeni@...hat.com>, Richard Cochran <richardcochran@...il.com>, Vinicius
Costa Gomes <vinicius.gomes@...el.com>, Sebastian Andrzej Siewior
<bigeasy@...utronix.de>, intel-wired-lan@...ts.osuosl.org,
netdev@...r.kernel.org
Subject: Re: [Intel-wired-lan] [PATCH iwl-next] igb: Retrieve Tx timestamp
directly from interrupt
On Thu Aug 21 2025, Miroslav Lichvar wrote:
> On Thu, Aug 21, 2025 at 01:38:44PM +0200, Kurt Kanzenbach wrote:
>> On Wed Aug 20 2025, Jacob Keller wrote:
>> > On 8/20/2025 12:56 AM, Miroslav Lichvar wrote:
>> >> But when I increase the rate to 200000, I get this:
>> >>
>> >> Without the patch:
>> >> NTP daemon TX timestamps : 35835
>> >> NTP kernel TX timestamps : 1410956
>> >> NTP hardware TX timestamps : 581575
>> >>
>> >> With the patch:
>> >> NTP daemon TX timestamps : 476908
>> >> NTP kernel TX timestamps : 646146
>> >> NTP hardware TX timestamps : 412095
>
>> Miroslav, can you test the following patch? Does this help?
>
> It seems better than with the original patch, but not as good as
> before, at least in the tests I'm doing. The maximum packet rate the
> server can handle is now only about 5% worse (instead of 40%), but the
> the number of missing timestamps on the server still seems high.
>
> With the new patch at 200000 requests per second:
> NTP daemon TX timestamps : 192404
> NTP kernel TX timestamps : 1318971
> NTP hardware TX timestamps : 418805
>
> I didn't try to adjust the aux worker priority.
Here's what I can see in the traces: In the current implementation, the
kworker runs directly after the IRQ on the *same* CPU. With the AUX
worker approach the kthread can be freely distributed to any other
CPU. This in turn involves remote wakeups etc.
You could try to pin the PTP AUX worker (e.g. called ptp0) with taskset
to the same CPU where the TS IRQs are processed. That might help to get
the old behavior back. Adjusting the priority is not necessary, both the
kworker and AUX thread run with 120 (SCHED_OTHER, nice value 0) by
default.
Thanks,
Kurt
Download attachment "signature.asc" of type "application/pgp-signature" (862 bytes)
Powered by blists - more mailing lists