Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp5019077imm; Tue, 11 Sep 2018 23:25:11 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZQQBCJH6GyaWgi9m8Vi5TOywTXZXs3qjHoFU4g83R4C+GHFaj/fSBPgPprXX48VzZXUQAu X-Received: by 2002:a17:902:9a8a:: with SMTP id w10-v6mr409725plp.14.1536733511278; Tue, 11 Sep 2018 23:25:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536733511; cv=none; d=google.com; s=arc-20160816; b=gBIMGjhwxo3VUNSLPK0o6D+yHOd2hhKnzpJwRz5e/2GKPPrM1SWHAWbtMvGDGc1z62 dDMB0c3Kw0zClqfdp6/ofouuoH/80gCZGuDrv1uc8wtZCHQozyykEN+eVpFib9c7Et6F Wyh3ZOEyzPl6zSb6mWL/URamYicsqypnF5VjvP10v16JrPOWlG+1fZsZx8BRRVBFqJ8N QCtwf/3LNqrHAv0xafw2VuPPxVfriwjEF/aGulNvbfzdf+qEz43LTysMuSpfRFVZXtad nlVZqEFcVVxGFJxjjEGVIeymfPqzuuZvnJTUCw9JG/4gSd5pCDiSL58yb8Hnyi7MplYh bc1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=zkXr+02czAwNKqE4LNQhPfmtnvWpE/IDmlBvLe4odcw=; b=cmzXT4C3+kWcthd0Cu8lmbiSWzJ0FEr0y6Noyz5hJZhJ5jeLnPEUT5OqLxte1JVlbI eABQUY28P2Wioj4K3NOFeC0+lTzlEpWZ2UGFEbgivPDaP59MFFZuDXH4DczDHMObiwYR 5VsXJOp/kn24khsDKRI7t+QvfLjZfRBl7ZLPqOyR1Q/4UopII6WqdY+/RVvOvaGk/df3 uwil5I2CezRb3R+PZf3sDsNhngFCoWLGE4Ir/VHrC1OhMEQh5BTTgJwNNRiDr83JJYfW /xFrfwyjKlIVoy1LUq3PADbl9c+4zcOnrpIeojsoqIoGHZLh86Nwu/lqKRrGtXycFYoi Fx4Q== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c10-v6si102825pgg.315.2018.09.11.23.24.55; Tue, 11 Sep 2018 23:25:11 -0700 (PDT) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727287AbeILL0U (ORCPT + 99 others); Wed, 12 Sep 2018 07:26:20 -0400 Received: from aws.guarana.org ([13.237.110.252]:48694 "EHLO aws.guarana.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725910AbeILL0U (ORCPT ); Wed, 12 Sep 2018 07:26:20 -0400 X-Greylist: delayed 526 seconds by postgrey-1.27 at vger.kernel.org; Wed, 12 Sep 2018 07:26:19 EDT Received: by aws.guarana.org (Postfix, from userid 1006) id 76624A1454; Wed, 12 Sep 2018 06:14:33 +0000 (UTC) Date: Wed, 12 Sep 2018 06:14:33 +0000 From: Kevin Easton To: "Jason A. Donenfeld" Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, davem@davemloft.net, gregkh@linuxfoundation.org, Andy Lutomirski , Thomas Gleixner , Samuel Neves , linux-arch@vger.kernel.org Subject: Re: [PATCH net-next v3 01/17] asm: simd context helper API Message-ID: <20180912061433.GA8484@ip-172-31-15-78> References: <20180911010838.8818-1-Jason@zx2c4.com> <20180911010838.8818-2-Jason@zx2c4.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180911010838.8818-2-Jason@zx2c4.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 10, 2018 at 07:08:21PM -0600, Jason A. Donenfeld wrote: > Sometimes it's useful to amortize calls to XSAVE/XRSTOR and the related > FPU/SIMD functions over a number of calls, because FPU restoration is > quite expensive. This adds a simple header for carrying out this pattern: > > simd_context_t simd_context = simd_get(); > while ((item = get_item_from_queue()) != NULL) { > encrypt_item(item, simd_context); > simd_context = simd_relax(simd_context); > } > simd_put(simd_context); > > The relaxation step ensures that we don't trample over preemption, and > the get/put API should be a familiar paradigm in the kernel. Given that it's always supposed to be used like that, mightn't it be better if simd_relax() took a pointer to the context, so the call is just simd_relax(&simd_context); ? The inlining means that there won't actually be a pointer dereference in the emitted code. If simd_put() also took a pointer then it could set the context back to HAVE_NO_SIMD as well? - Kevin