Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp9791245imu; Wed, 5 Dec 2018 10:16:42 -0800 (PST) X-Google-Smtp-Source: AFSGD/V6ogzSaTmsQXp1Y/pqzafrRxSNgCKdJf+SCRDf1x8nz9w7DvzuL2Cbvl5wvZ/T3yA0qpxg X-Received: by 2002:a17:902:6848:: with SMTP id f8mr24566846pln.300.1544033802655; Wed, 05 Dec 2018 10:16:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544033802; cv=none; d=google.com; s=arc-20160816; b=C2NypygG0uyUKKUjx91FHEDXN3a9VzMzyZNbDbWGzTKck3evC/zLdvvwcy8ZQC7uBx cz6jseR1O4vmqJlYrqMrsLlgRZ4eUWsxUIVjw7duF77k4YFA7WxOZCJHRPOwxK2Yl22O 5V2WTdxTOmgMjdDBYn//FIvELcMonBiOV+Y9q1mNXrUoV918GbdU6J8FNzH1nGd9A3rz SZ83WOogXSlT3TEEwo0B0z7anZ1HGfobBZfy4mYW5kzGbLXpHQlncWfVAIg9Mg3R2SAA j9tsazrN+TKzyWmEiJnN1o+7sUFUbmw5DIn6vkO0mfgIdvWTFa8jigQLVGq9aU6og8Cz +BjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=cEfPdIo/q5nG1QuLs6UeUP8h9511YM7N/guaUiRx30o=; b=CSTPcINll9j4VcU1ggyKI7Q6YKCSaVuKfy7SpC6NZ4vZLLdKPVOlslIEbmVTeV7g+e xukqVrNhzq+aZ35c05VZY9sBtLLQL1LXnH4JcHBFwhfErQJZeJfAtXGnuqRncCoRDEsA gKsihUrBVfg3Vpuke7Wzh2Jp2Y9rcYM18Duas0JoLCktQwwaipKP90utn1Kks3dwVQOv CU8GXyhDEieWK7jjGX9wnZBPw+NjvT1liZ59LH2alf0S0iGP1mYEtISRlvODe1wcQ/b6 wce6BDE7qI0b3097GhGTWou6yZeW6psmlDgHXVSknfxjro5RtoGHGDtqew8XcEEpM9RY 3EIA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n15si17389407pgk.27.2018.12.05.10.16.27; Wed, 05 Dec 2018 10:16:42 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728055AbeLESO1 (ORCPT + 99 others); Wed, 5 Dec 2018 13:14:27 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48342 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727257AbeLESO0 (ORCPT ); Wed, 5 Dec 2018 13:14:26 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2D298307CDDA; Wed, 5 Dec 2018 18:14:26 +0000 (UTC) Received: from localhost.localdomain.com (unknown [10.32.181.92]) by smtp.corp.redhat.com (Postfix) with ESMTP id ED30C1001F58; Wed, 5 Dec 2018 18:14:24 +0000 (UTC) From: Paolo Abeni To: netdev@vger.kernel.org Cc: "David S. Miller" , Eric Dumazet , Paul Turner , linux-kernel@vger.kernel.org Subject: [PATCH net-next v2 0/4] net: mitigate retpoline overhead Date: Wed, 5 Dec 2018 19:13:38 +0100 Message-Id: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.49]); Wed, 05 Dec 2018 18:14:26 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. rfc -> v1: - use branch prediction hints, as suggested by Eric v1 -> v2: - list explicitly the builtin function names in INDIRECT_CALL_*() - expand the recipients list [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 | 18 +++++++--- net/ipv6/tcpv6_offload.c | 7 ++-- net/ipv6/udp_offload.c | 7 ++-- 9 files changed, 119 insertions(+), 22 deletions(-) create mode 100644 include/linux/indirect_call_wrapper.h -- 2.19.2