From patchwork Wed May 25 06:12:30 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "\(Exiting\) Baolin Wang" X-Patchwork-Id: 68561 Delivered-To: patch@linaro.org Received: by 10.140.92.199 with SMTP id b65csp1033944qge; Tue, 24 May 2016 23:13:12 -0700 (PDT) X-Received: by 10.98.90.7 with SMTP id o7mr3196833pfb.110.1464156791861; Tue, 24 May 2016 23:13:11 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id hu6si10242407pad.196.2016.05.24.23.13.11 for ; Tue, 24 May 2016 23:13:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=fail (p=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755500AbcEYGNH (ORCPT ); Wed, 25 May 2016 02:13:07 -0400 Received: from mail-pa0-f48.google.com ([209.85.220.48]:33526 "EHLO mail-pa0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751856AbcEYGND (ORCPT ); Wed, 25 May 2016 02:13:03 -0400 Received: by mail-pa0-f48.google.com with SMTP id xk12so14388498pac.0 for ; Tue, 24 May 2016 23:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :in-reply-to:references; bh=JrnmqpJJckOrnPZH2ETGagU+nog3J7+1RSv1kF6Yn5o=; b=D8o/Tck65O31MUCNnMqH4SE2oDJTIUe2wr2eUUaynDSLEKXppBIfzRhMI8pKynQed4 2BRdkE56XTP3RwagC+6nU+eVJ2znXToCx90flq0ivIvxaZRk2TZuESpTfVBddmcOgyXo GS+igFMgUlLbyNZzEKDTDkDezBn3hyniLHAVM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:in-reply-to:references; bh=JrnmqpJJckOrnPZH2ETGagU+nog3J7+1RSv1kF6Yn5o=; b=kPgOzmefWGz7ZhbuxX3+9dymfSEEXXWJbm4ol3EOJYWGBWjtbEIktZ2brcBy7tW2nJ YkY/kRPiR9mTLosp9T5lstqpB35Q0IcWYp2wonIYSRYUFyHBuc9bIMdq9jPWn86rcO3Q iquiD1vXX91xlBIApn7KZM0ec7MXGQVmck95UxxXKakOHjhNH9sq2kpUFd3os3FcI8gN 2dQHUkjwPN0iXkfnDcJvMPTsrxxf5oe+AYA5tenaQfD2/t/i+4t6HL9+aJghVyE94yCR CYLEhFInLOROKUrVdRMuF7LN+8PNEYrYWmEdZSAt1D6ZM2BvbHcQtTo9NhOve6Yb/c8l P+Rw== X-Gm-Message-State: ALyK8tJwfCK/Jkp0m4vlShnzI7JFOHlzJTCzLohwiKXa71SEX0KDXIfAtpdSrKHCwyXTJV7J X-Received: by 10.67.13.144 with SMTP id ey16mr3041384pad.147.1464156782301; Tue, 24 May 2016 23:13:02 -0700 (PDT) Received: from baolinwangubtpc.spreadtrum.com ([175.111.195.49]) by smtp.gmail.com with ESMTPSA id l129sm17484335pfc.5.2016.05.24.23.12.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 24 May 2016 23:13:01 -0700 (PDT) From: Baolin Wang To: axboe@kernel.dk, agk@redhat.com, snitzer@redhat.com, dm-devel@redhat.com, herbert@gondor.apana.org.au, davem@davemloft.net Cc: ebiggers3@gmail.com, js1304@gmail.com, tadeusz.struk@intel.com, smueller@chronox.de, standby24x7@gmail.com, shli@kernel.org, dan.j.williams@intel.com, martin.petersen@oracle.com, sagig@mellanox.com, kent.overstreet@gmail.com, keith.busch@intel.com, tj@kernel.org, ming.lei@canonical.com, broonie@kernel.org, arnd@arndb.de, linux-crypto@vger.kernel.org, linux-block@vger.kernel.org, linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org, baolin.wang@linaro.org Subject: [RFC 2/3] crypto: Introduce CRYPTO_ALG_BULK flag Date: Wed, 25 May 2016 14:12:30 +0800 Message-Id: <7f0fef5fe473a451e352b2d42e1eed483fd28667.1464144791.git.baolin.wang@linaro.org> X-Mailer: git-send-email 1.7.9.5 In-Reply-To: References: In-Reply-To: References: Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Now some cipher hardware engines prefer to handle bulk block rather than one sector (512 bytes) created by dm-crypt, cause these cipher engines can handle the intermediate values (IV) by themselves in one bulk block. This means we can increase the size of the request by merging request rather than always 512 bytes and thus increase the hardware engine processing speed. So introduce 'CRYPTO_ALG_BULK' flag to indicate this cipher can support bulk mode. Signed-off-by: Baolin Wang --- include/crypto/skcipher.h | 7 +++++++ include/linux/crypto.h | 6 ++++++ 2 files changed, 13 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/include/crypto/skcipher.h b/include/crypto/skcipher.h index 0f987f5..d89d29a 100644 --- a/include/crypto/skcipher.h +++ b/include/crypto/skcipher.h @@ -519,5 +519,12 @@ static inline void skcipher_request_set_crypt( req->iv = iv; } +static inline unsigned int skcipher_is_bulk_mode(struct crypto_skcipher *sk_tfm) +{ + struct crypto_tfm *tfm = crypto_skcipher_tfm(sk_tfm); + + return crypto_tfm_alg_bulk(tfm); +} + #endif /* _CRYPTO_SKCIPHER_H */ diff --git a/include/linux/crypto.h b/include/linux/crypto.h index 6e28c89..a315487 100644 --- a/include/linux/crypto.h +++ b/include/linux/crypto.h @@ -63,6 +63,7 @@ #define CRYPTO_ALG_DEAD 0x00000020 #define CRYPTO_ALG_DYING 0x00000040 #define CRYPTO_ALG_ASYNC 0x00000080 +#define CRYPTO_ALG_BULK 0x00000100 /* * Set this bit if and only if the algorithm requires another algorithm of @@ -623,6 +624,11 @@ static inline u32 crypto_tfm_alg_type(struct crypto_tfm *tfm) return tfm->__crt_alg->cra_flags & CRYPTO_ALG_TYPE_MASK; } +static inline unsigned int crypto_tfm_alg_bulk(struct crypto_tfm *tfm) +{ + return tfm->__crt_alg->cra_flags & CRYPTO_ALG_BULK; +} + static inline unsigned int crypto_tfm_alg_blocksize(struct crypto_tfm *tfm) { return tfm->__crt_alg->cra_blocksize;