| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <87ms7vs6vk.fsf@jax.kurt.home>
Date: Tue, 19 Aug 2025 16:50:23 +0200
From: Kurt Kanzenbach <kurt@...utronix.de>
To: Miroslav Lichvar <mlichvar@...hat.com>
Cc: 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 Mon Aug 18 2025, Miroslav Lichvar wrote:
> On Fri, Aug 15, 2025 at 08:50:23AM +0200, Kurt Kanzenbach wrote:
>> Retrieve Tx timestamp directly from interrupt handler.
>>
>> 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, fetch the timestamp directly from the interrupt handler.
>>
>> The work queue code stays for the Intel 82576. Tested on Intel i210.
>
> I tested this patch on 6.17-rc1 with an Intel I350 card on a NTP
> server (chrony 4.4), measuring packet rates and TX timestamp accuracy
> with ntpperf. While the HW TX timestamping seems more reliable at some
> lower request rates, there seems to be about 40% drop in the overall
> performance of the server in how much requests it can handle (falling
> back to SW timestamps when HW timestamp is missed). Is this expected
> or something to be considered?
I have never ever used ntpperf before, so please bear with me. I've
setup two x86 machines with Debian Trixie, v6.17.0-rc1+ and Intel i210.
Installed ntpperf on one machine and chrony (v4.6) on the second. In the
chrony config there is 'hwtimestamp enp1s0'. I did run the first example
in ntpperf's README with the following results. 'rate' seems to be
higher with my patch applied. Anyway, your ntpperf output looks
completely different. What parameters are you using? I just want to
reproduce your results first.
* ntpperf with igb patch applied
Linux cml1 6.17.0-rc1+ #1 SMP PREEMPT_RT Tue Aug 19 12:56:41 CEST 2025 x86_64 GNU/Linux
Linux cml2 6.17.0-rc1+ #1 SMP PREEMPT_RT Tue Aug 19 12:56:41 CEST 2025 x86_64 GNU/Linux
root@...1:~/ntpperf# ./ntpperf -i enp1s0 -m 6c:b3:11:52:39:15 -d 192.168.123.1 -s 172.18.0.0/16 -B -H
| responses | response time (ns)
rate clients | lost invalid basic xleave | min mean max stddev
1000 100 0.00% 0.00% 100.00% 0.00% +15124 +16491 +166838 4773
1500 150 0.00% 0.00% 100.00% 0.00% +14589 +16163 +170222 4028
2250 225 0.00% 0.00% 100.00% 0.00% +14337 +15825 +172604 3356
3375 337 0.00% 0.00% 100.00% 0.00% +14267 +15549 +171365 2727
5062 506 0.00% 0.00% 100.00% 0.00% +14033 +15389 +177490 2384
7593 759 0.00% 0.00% 100.00% 0.00% +14307 +15418 +174652 1983
11389 1138 0.00% 0.00% 100.00% 0.00% +14100 +16551 +169245 6036
17083 1708 0.00% 0.00% 100.00% 0.00% +10077 +20077 +194647 9182
25624 2562 0.00% 0.00% 100.00% 0.00% +10007 +25572 +181577 14952
38436 3843 0.00% 0.00% 100.00% 0.00% +6851 +27466 +184041 14900
57654 5765 0.00% 0.00% 100.00% 0.00% +5164 +29218 +246544 16169
86481 8648 0.00% 0.00% 100.00% 0.00% +5346 +36063 +179512 14388
129721 12972 0.00% 0.00% 100.00% 0.00% +7934 +49386 +229427 17600
194581 16384 0.00% 0.00% 100.00% 0.00% +10760 +54961 +248325 18860
291871 16384 0.00% 0.00% 100.00% 0.00% +13207 +57193 +248870 16908
437806 16384 25.42% 0.00% 74.58% 0.00% +211479 +275061 +703480 20529
656709 16384 50.32% 0.00% 49.68% 0.00% +230344 +292741 +485387 19119
* ntpperf without igb patch applied
Linux cml1 6.17.0-rc1+ #3 SMP PREEMPT_RT Tue Aug 19 15:31:35 CEST 2025 x86_64 GNU/Linux
Linux cml2 6.17.0-rc1+ #3 SMP PREEMPT_RT Tue Aug 19 15:31:35 CEST 2025 x86_64 GNU/Linux
root@...1:~/ntpperf# ./ntpperf -i enp1s0 -m 6c:b3:11:52:39:15 -d 192.168.123.1 -s 172.18.0.0/16 -B -H
| responses | response time (ns)
rate clients | lost invalid basic xleave | min mean max stddev
1000 100 0.00% 0.00% 100.00% 0.00% +18246 +19931 +174292 4947
1500 150 0.00% 0.00% 100.00% 0.00% +17934 +19494 +194876 4368
2250 225 0.00% 0.00% 100.00% 0.00% +17969 +19254 +177394 3449
3375 337 0.00% 0.00% 100.00% 0.00% +17687 +19090 +179947 2807
5062 506 0.00% 0.00% 100.00% 0.00% +17798 +18999 +175463 2403
7593 759 0.00% 0.00% 100.00% 0.00% +17901 +19039 +176656 1984
11389 1138 0.00% 0.00% 100.00% 0.00% +17192 +20318 +184805 6802
17083 1708 0.00% 0.00% 100.00% 0.00% +14241 +24428 +185137 10118
25624 2562 0.00% 0.00% 100.00% 0.00% +4819 +22667 +201990 7962
38436 3843 0.00% 0.00% 100.00% 0.00% +3869 +17957 +192566 8171
57654 5765 0.00% 0.00% 100.00% 0.00% +2529 +14036 +173719 6240
86481 8648 0.00% 0.00% 100.00% 0.00% +2774 +13642 +201026 5284
129721 12972 0.00% 0.00% 100.00% 0.00% +2670 +14699 +242395 6692
194581 16384 0.00% 0.00% 100.00% 0.00% +2520 +19712 +329254 9571
291871 16384 1.37% 0.00% 98.63% 0.00% +2818 +77396 +15480693 182286
437806 16384 24.69% 0.00% 75.31% 0.00% +108662 +246855 +2306431 38520
Could not send requests at rate 656709
Thanks,
Kurt
Download attachment "signature.asc" of type "application/pgp-signature" (862 bytes)
Powered by blists - more mailing lists