Re: [tip:x86/build] x86, retpolines: Raise limit for generating indirect calls from switch-case

[David Woodhouse]

On Thu, 2019-02-28 at 03:12 -0800, tip-bot for Daniel Borkmann wrote:
> Commit-ID:  ce02ef06fcf7a399a6276adb83f37373d10cbbe1
> Gitweb:     https://git.kernel.org/tip/ce02ef06fcf7a399a6276adb83f37373d10cbbe1
> Author:     Daniel Borkmann <daniel@xxxxxxxxxxxxx>
> AuthorDate: Thu, 21 Feb 2019 23:19:41 +0100
> Committer:  Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> CommitDate: Thu, 28 Feb 2019 12:10:31 +0100
> 
> x86, retpolines: Raise limit for generating indirect calls from switch-case
> 
> From networking side, there are numerous attempts to get rid of indirect
> calls in fast-path wherever feasible in order to avoid the cost of
> retpolines, for example, just to name a few:
> 
>   * 283c16a2dfd3 ("indirect call wrappers: helpers to speed-up indirect calls of builtin")
>   * aaa5d90b395a ("net: use indirect call wrappers at GRO network layer")
>   * 028e0a476684 ("net: use indirect call wrappers at GRO transport layer")
>   * 356da6d0cde3 ("dma-mapping: bypass indirect calls for dma-direct")
>   * 09772d92cd5a ("bpf: avoid retpoline for lookup/update/delete calls on maps")
>   * 10870dd89e95 ("netfilter: nf_tables: add direct calls for all builtin expressions")
>   [...]
> 
> 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. 

+HJL

This is a GCC bug, surely? It should know how expensive each
instruction is, and choose which to use accordingly. That should be
true even when the indirect branch "instruction" is a retpoline, and
thus enormously expensive.

I believe this is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86952 so
please at least reference that bug, and be prepared to turn this hack
off when GCC is fixed.

Attachment: smime.p7s
Description: S/MIME cryptographic signature