Received: by 2002:ac0:8845:0:0:0:0:0 with SMTP id g63csp895364img; Tue, 26 Feb 2019 10:22:53 -0800 (PST) X-Google-Smtp-Source: AHgI3IYCkHNpCK22iDpP/7djae4GqbyGZSuysYgetcK8ziKuekoTvaIrUs+xexrRdhHx+BjO/xox X-Received: by 2002:a63:6605:: with SMTP id a5mr25734305pgc.372.1551205373315; Tue, 26 Feb 2019 10:22:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551205373; cv=none; d=google.com; s=arc-20160816; b=I2LtWKj1/I+NWTmQ0/f0qkRKHiaQ3So6df+H38qw6zbydpzxSMFLcCS2TyiN0UawVy X29ZG0X+j8G5nO5iobqmOUZ8mTIBrcgEVnS7frUXf1uPUhXHnrYQGlz5mciuiQUiXlYr iCxAEMYN1oU2VXDxjMYcqSsiH5B6B7zpWZeovhLoSGz2Jzyrx13ZFUfjx+2+aHs1jlz9 mvYje6/yHF4KmgC9IJldkP2MAEQpG1CaDInGX1+C+PM4YjTeS4E2e/KH1+f8vRHioiT6 iZKD8xTIgMTEqYIys/T2W3y3SyPStvOLnLnIt+qMkbBUnVY5u3YxdZaNB0XHWuD8ILzf Y6mw== 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:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=rXhPxCyfwc/K+JPxZkycecoAUFiC126VMt5sJ0MB4Es=; b=Y5lw1Zz+g27CYA8spZX6gDiM5668UFdkhlwBuouLFVs/RGA0rQRDe26cjsgYWkCFnk uiHnZuzdwFmhtT2hpSHxrFbJhaFS+3CN7OoKJ4m7UYKh8YQQz+6ZT5aH82CniF4ryyrv 7H32jG0P+QSvOamxWscbiA/jOAz2x2jqDMFVw4aOEwk13pD1gvPC7R09IxJqAQwRBlBB b04F6CAbWWUU4HTj6QJ3VPERIXmGkq+Tjism2cj46ImMQfiLPKGzwCo/WYDPTQILg6AQ wViq8KonTUJ2gObBy01Pp1nBZ81Jxv8GNJVrwE/dIKyDxnW8WlBsLsHNu3LJLTFpvQB1 cZuQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Ai7DxOn9; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r187si7787079pfr.124.2019.02.26.10.22.38; Tue, 26 Feb 2019 10:22:53 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Ai7DxOn9; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729129AbfBZSVC (ORCPT + 99 others); Tue, 26 Feb 2019 13:21:02 -0500 Received: from mail-qt1-f196.google.com ([209.85.160.196]:40478 "EHLO mail-qt1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728736AbfBZSVB (ORCPT ); Tue, 26 Feb 2019 13:21:01 -0500 Received: by mail-qt1-f196.google.com with SMTP id j36so16016521qta.7; Tue, 26 Feb 2019 10:21:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rXhPxCyfwc/K+JPxZkycecoAUFiC126VMt5sJ0MB4Es=; b=Ai7DxOn9Q/vUeG3c6omQbwHjCarG8U+AyDwppqidt3ZvTEzewR6mjd1xNAAETbJYhn HVHL3xLf9owR+p2Yhm7TMT1zP+imzT4BRHrQcJ0WOW6KLnw4eXQMsgPuvB3ZRMBsriAH zHgSacq9RYe0rwPy2QPkIOWwL9sf5crYRGEOPGjIAjgg/RZlc08MeGw2eAnHD4EaQVvS zXERVipfgEai5lTKNkBhJYsk/SHlw3ra7WlWJ94BzlntSu1TmZeWisdjbQIS9Ibt9lRD 2HgfUQ5pnwFIXsgdC4C/9rtPzZIaO2smNCV/k6HJLctm48G/djZ4TsCcs1l1pafapP8Y n+Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rXhPxCyfwc/K+JPxZkycecoAUFiC126VMt5sJ0MB4Es=; b=MNnqBICqpaaVh4/E2vvvaWIii3mkDZ5e3qVu2+N/7paf/9mdBu0WokGBNrv2/AZPY1 XKGwq3e9QHS8ery7ik8VpF9t8P9hSsbY3TQl5BUkQ7GX1Xp0w1BA54f6Rm0J0j37GbMa 4nb0r2FU/wATUCdPfFRkVF3SyqTOkktupvgITlr8i2sa19Y8KF7HkWxz5ezzLuqVfnAH vSUGuGUyHSjt8l4L/byDZKDz3lb6h93LLgYwD05thLuEzmwvs8Wdcjxsn4HV7WQpLPoD xG6lP6zgqHoogNNLqIdj7Mj0idFLK8rObrDE/V/g7r9uNv/EEt1WLC2f+4TbxIEwnDOq 77TQ== X-Gm-Message-State: AHQUAuZlGF3iEI4WpuXHiSG39r5n1WLYRO7Blc92ko3gLR2zZW4SKph+ DBA1cTPg1B3jKNrk86wCNqXeNgeMC4Ij0i68PcJwlNUb X-Received: by 2002:ac8:6887:: with SMTP id m7mr18745059qtq.381.1551205260288; Tue, 26 Feb 2019 10:21:00 -0800 (PST) MIME-Version: 1.0 References: <20190221221941.29358-1-daniel@iogearbox.net> <20190222083131.5a141e23@carbon> In-Reply-To: <20190222083131.5a141e23@carbon> From: =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= Date: Tue, 26 Feb 2019 19:20:50 +0100 Message-ID: Subject: Re: [PATCH] x86, retpolines: raise limit for generating indirect calls from switch-case To: Jesper Dangaard Brouer Cc: Daniel Borkmann , tglx@linutronix.de, LKML , Netdev , "David S . Miller" , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Magnus Karlsson , Alexei Starovoitov , Peter Zijlstra , David Woodhouse , Andy Lutomirski , Borislav Petkov , Linus Torvalds Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 22 Feb 2019 at 08:32, Jesper Dangaard Brouer wr= ote: > > On Thu, 21 Feb 2019 23:19:41 +0100 > Daniel Borkmann wrote: > > > Recent work on XDP from Bj=C3=B6rn 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=C3=B6rn 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 > > Thanks for following up on this Daniel, I definitely prefer a switch-statement over the if-else-messiness in this context. Thanks for doing the deep-dive, Daniel! FWIW, Acked-by: Bj=C3=B6rn T=C3=B6pel > -- > Best regards, > Jesper Dangaard Brouer > MSc.CS, Principal Kernel Engineer at Red Hat > LinkedIn: http://www.linkedin.com/in/brouer