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

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <edd81dec-c914-45c9-9618-6042fdab60da@intel.com>
Date: Mon, 25 Aug 2025 16:23:25 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: Kurt Kanzenbach <kurt@...utronix.de>, Miroslav Lichvar
	<mlichvar@...hat.com>
CC: Sebastian Andrzej Siewior <bigeasy@...utronix.de>, 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>, Paul Menzel
	<pmenzel@...gen.mpg.de>, Vadim Fedorenko <vadim.fedorenko@...ux.dev>,
	<intel-wired-lan@...ts.osuosl.org>, <netdev@...r.kernel.org>
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v2] igb: Convert Tx
 timestamping to PTP aux worker



On 8/25/2025 2:22 AM, Kurt Kanzenbach wrote:
> On Mon Aug 25 2025, Miroslav Lichvar wrote:
>> On Sat, Aug 23, 2025 at 09:29:36AM +0200, Kurt Kanzenbach wrote:
>>> Also I couldn't really see a performance degradation with ntpperf.
>>
>> I was testing with an I350, not I210. Could that make a difference?
> 
> Jup, it could make a difference.
> 

Yes, that could make a significant difference. I350 is a different MAC
architecture. According to its datasheet, I can see that it uses a
similar TXTSTMP registers, and it appears to have an interrupt cause,
TIME_SYNC bit set which an additional cause register TSICR indicates
which specific event occurred.

It does look like the logic in the driver checks TSICR and doesn't just
randomly call this function each time, as it relies on the presence of
the TSICR register.. Hm.

At first I thought it might be because I350 also has an interrupt
trigger for receive timestamps, but this cause is masked in the TSIM
register, so it shouldn't be a concern.
>>
>>> 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.
>>
>> That's ntpperf giving up as the HW is too slow to send requests at
>> that rate (with a single process calling sendmmsg() in a loop). You
>> can add the -l option to force ntpperf to continue, but the printed
>> rate values will no longer be accurate, you would need to measure it
>> by some other way, e.g. by monitoring the interface packet counters.
> 
> I see.
> 
> Thanks,
> Kurt



Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (237 bytes)