[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DM5PR07MB3148D87C62159523B750CD20E5690@DM5PR07MB3148.namprd07.prod.outlook.com>
Date: Tue, 27 Dec 2016 11:39:21 +0000
From: "Challa, Mahipal" <Mahipal.Challa@...ium.com>
To: Herbert Xu <herbert@...dor.apana.org.au>,
Jan Glauber <Jan.Glauber@...ium.com>
CC: "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"David S . Miller" <davem@...emloft.net>,
"Nair, Vishnu" <Vishnu.Nair@...ium.com>
Subject: Re: [RFC PATCH 0/3] Cavium ThunderX ZIP driver
Hi Herbert,
Thanks for your response
>Hi Jan:
On Mon, Dec 12, 2016 at 04:04:36PM +0100, Jan Glauber wrote:
> >
> >this series adds support for hardware accelerated compression & decompression
> >as found on ThunderX (arm64) SOCs. I've been reviewing this driver internally
> >for some time and would like to get feedback on the RFC to see if this goes
> >into the right direction and to see if there are any concerns.
> >
> >We've discussed switching to the new acomp algorithm but for the time being
> >decided against acomp because our test cases are not yet supported with it.
> OK. Do you see any major problems in converting this over to acomp?
Mahipal: One major issue is, the kernel use cases to validate the Cavium ThunderX ZIP driver are "ZSWAP" and "IPComp" which are not yet supported with scomp-acomp framework.
Regards,
-Mahipal
From: Herbert Xu <herbert@...dor.apana.org.au>
Sent: Tuesday, December 27, 2016 2:32 PM
To: Jan Glauber
Cc: linux-crypto@...r.kernel.org; linux-kernel@...r.kernel.org; David S . Miller; Challa, Mahipal; Nair, Vishnu
Subject: Re: [RFC PATCH 0/3] Cavium ThunderX ZIP driver
Hi Jan:
On Mon, Dec 12, 2016 at 04:04:36PM +0100, Jan Glauber wrote:
>
> this series adds support for hardware accelerated compression & decompression
> as found on ThunderX (arm64) SOCs. I've been reviewing this driver internally
> for some time and would like to get feedback on the RFC to see if this goes
> into the right direction and to see if there are any concerns.
>
> We've discussed switching to the new acomp algorithm but for the time being
> decided against acomp because our test cases are not yet supported with it.
OK. Do you see any major problems in converting this over to acomp?
Thanks,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists