From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753882AbcA0I0Z (ORCPT ); Wed, 27 Jan 2016 03:26:25 -0500 Received: from mga09.intel.com ([134.134.136.24]:27455 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752998AbcA0I0V (ORCPT ); Wed, 27 Jan 2016 03:26:21 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,354,1449561600"; d="scan'208";a="735005640" Subject: Re: [PATCH v2 04/10] crypto/compress: add asynchronous compression support To: Herbert Xu References: <1453796112-14273-1-git-send-email-iamjoonsoo.kim@lge.com> <1453796112-14273-5-git-send-email-iamjoonsoo.kim@lge.com> <20160127074140.GA30335@gondor.apana.org.au> <56A878C9.8050202@intel.com> <20160127080355.GA31330@gondor.apana.org.au> <20160127080926.GA31516@gondor.apana.org.au> CC: Joonsoo Kim , "David S. Miller" , Sergey Senozhatsky , Minchan Kim , Dan Streetman , , , Joonsoo Kim From: "Li, Weigang" Message-ID: <56A87F28.9050101@intel.com> Date: Wed, 27 Jan 2016 16:26:16 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20160127080926.GA31516@gondor.apana.org.au> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.239.127.40] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/27/2016 4:09 PM, Herbert Xu wrote: > On Wed, Jan 27, 2016 at 04:03:55PM +0800, Herbert Xu wrote: >> On Wed, Jan 27, 2016 at 03:59:05PM +0800, Li, Weigang wrote: >>> >>> The acomp is also SG-based, while scomp only accepts flat buffer. >> >> Right, but do we need a pointer-based scomp at all? IPComp would >> certainly be better off with an SG-based interface. Any other >> users of compression are presumably dealing with large amounts >> of data where an SG interface would make more sense. >> >> A pointer interface makes sense for shash because you may be hashing >> 16 bytes at a time. Nobody sane is going to be compressing 16 bytes, >> or are they? > > Note that I'm fine with keeping an scomp interface underneath > for those algorithms where the best way to handle SG input is > to linearise things. But I would prefer that this interface is > not exposed to kernel users unless it is absolutely required. > > Cheers, > Thanks for your comments, Herbert. I Agree, SG-list based compression API makes more sense. Maybe Joonsoo can comment on this.