From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932413AbbKQXAE (ORCPT <rfc822;w@1wt.eu>);
	Tue, 17 Nov 2015 18:00:04 -0500
Received: from mga01.intel.com ([192.55.52.88]:49706 "EHLO mga01.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1754073AbbKQXAC (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 17 Nov 2015 18:00:02 -0500
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.20,310,1444719600"; 
   d="scan'208";a="822576189"
Message-ID: <1447801169.4933.28.camel@schen9-desk2.jf.intel.com>
Subject: Re: [PATCH v2 1/5] crypto: Multi-buffer encryptioin infrastructure
 support
From: Tim Chen <tim.c.chen@linux.intel.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "H. Peter Anvin" <hpa@zytor.com>, "David S.Miller" <davem@davemloft.net>,
        Stephan Mueller <smueller@chronox.de>,
        Chandramouli Narayanan <mouli_7982@yahoo.com>,
        Vinodh Gopal <vinodh.gopal@intel.com>,
        James Guilford <james.guilford@intel.com>,
        Wajdi Feghali <wajdi.k.feghali@intel.com>,
        Jussi Kivilinna <jussi.kivilinna@iki.fi>, linux-crypto@vger.kernel.org,
        linux-kernel@vger.kernel.org
Date: Tue, 17 Nov 2015 14:59:29 -0800
In-Reply-To: <20151117130633.GB8032@gondor.apana.org.au>
References: <cover.1446158797.git.tim.c.chen@linux.intel.com>
	 <1446157263.14635.15.camel@schen9-desk2.jf.intel.com>
	 <20151117130633.GB8032@gondor.apana.org.au>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.8.5 (3.8.5-2.fc19) 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, 2015-11-17 at 21:06 +0800, Herbert Xu wrote:
> On Thu, Oct 29, 2015 at 03:21:03PM -0700, Tim Chen wrote:
> > 
> > c) Add support to crypto scatterwalk support that can sleep during
> > encryption operation, as we may have buffers for jobs in data lanes
> > that are half-finished, waiting for additional jobs to come to fill
> > empty lanes before we start the encryption again.  Therefore, we need to
> > enhance crypto walk with the option to map data buffers non-atomically.
> > This is done by algorithms run from crypto daemon who knows it is safe
> > to do so as it can save and restore FPU state in correct context.
> 
> What about the existing ablkcipher scatterwalk helpers?
> 
> Cheers,

I suppose blkcipher was originally used because we 
were under the impression that there are less buffer copying
and less allocation of intermediate buffers
with blkcipher walk. 

But looking at the blkcipher walk and ablkcipher
walk code more carefully now, I am not sure that's really true
as it seems like ablkcipher keep all intermediate buffers till the
end and copy them to destination in one shot while blkcipher does
that at walk of every chunk.  The advantage of blkcipher is
you don't have as many outstanding buffers in a list.  If there's
really not much speed difference, I can try to use ablkcipher.

Herbert, would you prefer me to use ablkcipher scatter walk instead,
assuming the overhead of both walk are about the same?

Thanks.

Tim