netdev - Re: [PATCH net-next] net_sched: sch_fq: tweak unlikely() hints in fq

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: <CANn89iLi8Z0+910hBn1JK6M+AFtbr=HW2p0yRTPZNjG8XcZLgg@mail.gmail.com>
Date: Wed, 4 Feb 2026 19:43:12 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: Jamal Hadi Salim <jhs@...atatu.com>
Cc: "David S . Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, 
	Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, Jiri Pirko <jiri@...nulli.us>, 
	netdev@...r.kernel.org, eric.dumazet@...il.com
Subject: Re: [PATCH net-next] net_sched: sch_fq: tweak unlikely() hints in fq_dequeue()

On Wed, Feb 4, 2026 at 7:25 PM Jamal Hadi Salim <jhs@...atatu.com> wrote:
>
>
> While it looks rational you didnt mention any numbers.

It is a very long process, one spot at a time.
Some cpus have a limited amount of return addresses in their RAS
branch predictor.
I am seeing high costs for functions needing a stack canary, for which
clang can not use tail calls.
When cpu returns back to these functions, we see a stall when
1) checking the stack canary
2) return from the function

I am not repeating the rationale on each patch, because we will have
maybe one hundred of them :/

This is also one of the reasons I am working on IPv6 stack to remove
stack canaries by all means.

> Iam curious, is it always _guaranteed_ that inlining improves performance?

Not always, but here the clang compiler was not inlining it because of
the wrong unlikely().

>
> Reviewed-by: Jamal Hadi Salim <jhs@...atatu.com>

Note : A stack canary is enforced in fq_enqueue() (because of the
tofree[] array in fq_gc()),
I will send a patch to remove it soon.

Thanks !