net: mitigate retpoline overhead
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v3 Latest4 patches 4 repliesIn review
- v24 patches 10 repliesSuperseded
- v14 patches 7 repliesSuperseded
Changes in v3 from the cover letter
- fix build error with CONFIG_IPV6=m
Patches in v3 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/4 | indirect call wrappers: helpers to speed-up indirect calls of builtininclude/ | +51 | 0 replies | |
| 2/4 | net: use indirect call wrappers at GRO network layerinclude/ net/ net/ | +18 | 0 replies | |
| 3/4 | net: use indirect call wrappers at GRO transport layerinclude/ net/ net/ +4 more | +61 | 0 replies | |
| 4/4 | udp: use indirect call wrappers for GRO socket lookupnet/ | +6 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v3 yet.
Cover letter [PATCH net-next v3 0/4] net: mitigate retpoline overhead
The spectre v2 counter-measures, aka retpolines, are a source of measurable overhead[1]. We can partially address that when the function pointer refers to a builtin symbol resorting to a list of tests vs well-known builtin function and direct calls.
Experimental results show that replacing a single indirect call via retpoline with several branches and a direct call gives performance gains even when multiple branches are added - 5 or more, as reported in [2].
This may lead to some uglification around the indirect calls. In netconf 2018 Eric Dumazet described a technique to hide the most relevant part of the needed boilerplate with some macro help.
This series is a [re-]implementation of such idea, exposing the introduced helpers in a new header file. They are later leveraged to avoid the indirect call overhead in the GRO path, when possible.
Overall this gives > 10% performance improvement for UDP GRO benchmark and smaller but measurable for TCP syn flood.
The added infra can be used in follow-up patches to cope with retpoline overhead in other points of the networking stack (e.g. at the qdisc layer) and possibly even in other subsystems.
v2 -> v3:
- fix build error with CONFIG_IPV6=m
v1 -> v2:
- list explicitly the builtin function names in INDIRECT_CALL_*(), as suggested by Ed Cree
- expand the recipients list
rfc -> v1:
- use branch prediction hints, as suggested by Eric
[1] http://vger.kernel.org/netconf2018_files/PaoloAbeni_netconf2018.pdf
[2] https://linuxplumbersconf.org/event/2/contributions/99/attachments/98/117/lpc18_paper_af_xdp_perf-v2.pdf
Paolo Abeni (4):
indirect call wrappers: helpers to speed-up indirect calls of builtin
net: use indirect call wrappers at GRO network layer
net: use indirect call wrappers at GRO transport layer
udp: use indirect call wrappers for GRO socket lookup
include/linux/indirect_call_wrapper.h | 51 +++++++++++++++++++++++++++ include/net/inet_common.h | 9 +++++ net/core/dev.c | 15 ++++++-- net/ipv4/af_inet.c | 13 +++++-- net/ipv4/tcp_offload.c | 6 ++-- net/ipv4/udp_offload.c | 15 +++++--- net/ipv6/ip6_offload.c | 35 +++++++++++++++--- net/ipv6/tcpv6_offload.c | 7 ++-- net/ipv6/udp_offload.c | 7 ++-- 9 files changed, 136 insertions(+), 22 deletions(-) create mode 100644 include/linux/indirect_call_wrapper.h
Signature · 1 line
2.19.2