Received: by 10.192.165.156 with SMTP id m28csp204705imm; Wed, 18 Apr 2018 20:27:27 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+8IBtXRiVdGIMD6l/Ehvb7TwuaXEbIuVLTgJb01/aMcKYaFv41eRehr5JBQunItMnPh74F X-Received: by 10.101.73.142 with SMTP id r14mr2354168pgs.78.1524108447778; Wed, 18 Apr 2018 20:27:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524108447; cv=none; d=google.com; s=arc-20160816; b=F3lbWhnkcHw2rGESFiMtgiu7kCiVcsqlTF6TuLwTJ/Tr0wmET5WaWRNV/1edGJPqqF TtWsmSjXbzW64SFCykKHkq1CVJtrSGgAG51PDqdqTuHbvC3+lfiznbLY3qerHIx4zPVR VsESMxD0mrAuaL6QsLsjEQjkNSd4WhwrGcIrySPWbmgh6Z2y1yWP4xI9a4ojCOF100X4 c16bU7clWVd/ZUgbHJnkhb8nQILjDxhs4DG37xts4K8t7NYWADr/6pRIw3QWev/T+5Dy Q/4Q5i0fNSaKV8SBk9SUYkDtxfmA4FXLvfQlSDHCdKzGRCEV0kmKu//5z03LZ7Mu6Svm h5Yg== 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:arc-authentication-results; bh=IQ1HQEKcIxZFc8irEqRN9e4WjchBlDmXdVAy6vl40vE=; b=vtKKFLpv7wAXL9o5ahbtyyUzIoq3n/LtzwiiUg/s7RGA+7KOfsgoZqeOSmEgT9Myd1 cAwO1Akz8jgxhtduO8pCWcm3t+yWqj1vCA8z5ieHxaNYRc6G1jczPD7DdXjDUyo6vtp8 Diq0rq36LnIn+v3suIUsIez2r0NieC72DugjYTmegFer5aAuRtpkteTWP3vjLqRcQaWw vFmje0N06SSLUt+GfiC2YD5Q+1jABxhGOeI30IUKjzM7iSh3eycma5pxwRUP+7/EZLN4 SL5FFMWomPyfO7GvHp8BCgrfFdGsMioMnKGzKIl71jrrwG/1RiaBVC3JepNWh62LQbSt xPbg== 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 a62si2222951pgc.296.2018.04.18.20.27.13; Wed, 18 Apr 2018 20:27:27 -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 S1753059AbeDSDZc (ORCPT + 99 others); Wed, 18 Apr 2018 23:25:32 -0400 Received: from orcrist.hmeau.com ([104.223.48.154]:44982 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751032AbeDSDZb (ORCPT ); Wed, 18 Apr 2018 23:25:31 -0400 Received: from gondobar.mordor.me.apana.org.au ([192.168.128.4] helo=gondobar) by deadmen.hmeau.com with esmtps (Exim 4.89 #2 (Debian)) id 1f90CP-0004r6-SH; Thu, 19 Apr 2018 11:25:29 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1f90CL-0008UH-N7; Thu, 19 Apr 2018 11:25:25 +0800 Date: Thu, 19 Apr 2018 11:25:25 +0800 From: Herbert Xu To: "Dey, Megha" Cc: "linux-kernel@vger.kernel.org" , "linux-crypto@vger.kernel.org" , "davem@davemloft.net" Subject: Re: [PATCH V8 1/5] crypto: Multi-buffer encryption infrastructure support Message-ID: <20180419032525.6csodbz6lrksyudd@gondor.apana.org.au> References: <1515542948-24041-1-git-send-email-megha.dey@linux.intel.com> <1515542948-24041-2-git-send-email-megha.dey@linux.intel.com> <20180118113905.GA19904@gondor.apana.org.au> <1516322661.2526.3.camel@megha-Z97X-UD7-TH> <20180316145351.GA6231@gondor.apana.org.au> <20180418110115.v2w3o5yfv4u3gc4r@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 19, 2018 at 12:54:16AM +0000, Dey, Megha wrote: > > Yeah I think I misunderstood. I think what you mean is to remove mcryptd.c completely and avoid the extra layer of indirection to call the underlying algorithm, instead call it directly, correct? > > So currently we have 3 algorithms registered for every multibuffer algorithm: > name : __sha1-mb > driver : mcryptd(__intel_sha1-mb) > > name : sha1 > driver : sha1_mb > > name : __sha1-mb > driver : __intel_sha1-mb > > If we remove mcryptd, then we will have just the 2? It should be down to just one, i.e., the current inner algorithm. It's doing all the scheduling work already so I don't really see why it needs the wrappers around it. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt