netdev - Re: [PATCH net-next v15 03/15] net: homa: create shared Homa header files

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CANn89i+yjrhykQ1FEaKoq4tPAutR44o3FbdNH_sw2R9dm2jMkw@mail.gmail.com>
Date: Wed, 27 Aug 2025 05:16:26 -0700
From: Eric Dumazet <edumazet@...gle.com>
To: John Ousterhout <ouster@...stanford.edu>
Cc: Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org, horms@...nel.org, 
	kuba@...nel.org
Subject: Re: [PATCH net-next v15 03/15] net: homa: create shared Homa header files

On Tue, Aug 26, 2025 at 4:11 PM John Ousterhout <ouster@...stanford.edu> wrote:

> I feel pretty strongly about retaining the use of TSC on Intel
> platforms. As I have said before, Homa is attempting to operate in a
> much more aggressive latency domain than Linux is used to, and
> nanoseconds matter. I have been using TSC on Intel and AMD platforms
> for more than 15 years and I have never had any problems. Is there a
> specific inconsistency you know of that will cause "unexpected issues
> in the most dangerous situations"? If not, I would prefer to retain
> the use of TSC until someone can identify a real problem. Note that
> the choice of clock is now well encapsulated, so if a change should
> become necessary it will be very easy to make.

Real cost in these helpers on modern cpus is in rdtscp instruction.

And using rdtsc (rdtsc()) instead of rdtscp (rdtsc_ordered()) is not
measuring anything useful
because of speculation.

Using get_cycles() in networking is simply a big no from us.

We do not want to deal with all these #ifdef CONFIG_X86_TSC games.