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: <20190222083131.5a141e23@carbon> Date: Fri, 22 Feb 2019 08:31:31 +0100 From: Jesper Dangaard Brouer <brouer@...hat.com> To: Daniel Borkmann <daniel@...earbox.net> Cc: tglx@...utronix.de, linux-kernel@...r.kernel.org, netdev@...r.kernel.org, "David S . Miller" <davem@...emloft.net>, Björn Töpel <bjorn.topel@...el.com>, Magnus Karlsson <magnus.karlsson@...el.com>, Alexei Starovoitov <ast@...nel.org>, Peter Zijlstra <peterz@...radead.org>, David Woodhouse <dwmw2@...radead.org>, Andy Lutomirski <luto@...nel.org>, Borislav Petkov <bp@...en8.de>, Linus Torvalds <torvalds@...ux-foundation.org>, brouer@...hat.com Subject: Re: [PATCH] x86, retpolines: raise limit for generating indirect calls from switch-case On Thu, 21 Feb 2019 23:19:41 +0100 Daniel Borkmann <daniel@...earbox.net> wrote: > Recent work on XDP from Björn and Magnus additionally found that > manually transforming the XDP return code switch statement with > more than 5 cases into if-else combination would result in a > considerable speedup in XDP layer due to avoidance of indirect > calls in CONFIG_RETPOLINE enabled builds. On i40e driver with > XDP prog attached, a 20-26% speedup has been observed [0]. Aside > from XDP, there are many other places later in the networking > stack's critical path with similar switch-case processing. Rather > than fixing every XDP-enabled driver and locations in stack by > hand, it would be good to instead raise the limit where gcc would > emit expensive indirect calls from the switch under retpolines I'm very happy to see this. Thanks to Björn for finding, analyzing and providing hand-coded-if-else code that demonstrated the performance issue for XDP. But I do think this GCC case-values-threshold param is a better and more generic solution to the issue we observed and measured in XDP land. And hopefully other parts of the network stack and kernel will also benefit. Acked-by: Jesper Dangaard Brouer <brouer@...hat.com> Thanks for following up on this Daniel, -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer
Powered by blists - more mailing lists