Re: algif for compression?

[abed mohammad kamaluddin]

Hi Stephen,

> If you follow the AF_ALG implementations that are currently in the kernel, a
> calling application receives two file descriptors. The first file descriptor
> is the reference to a tfm, the second is the reference to a particular
> request.
>
> Wouldn't those file descriptors be the reference you are looking for?

Those descriptors are sufficient to pass data from userspace
applications to the algif interface.
However the issue is passing those from the interface to the driver
using the current acomp API's.
This is the currently exposed interface to the comp framework. Am I
missing something here?

int (*compress)(struct acomp_req *req);
int (*decompress)(struct acomp_req *req);

struct acomp_req {
struct crypto_async_request base;
struct scatterlist *src;
struct scatterlist *dst;
unsigned int slen;
unsigned int dlen;
u32 flags;
void *__ctx[] CRYPTO_MINALIGN_ATTR;
};


Thanks
Abed



On Mon, Apr 3, 2017 at 12:56 PM, Stephan Müller  wrote:
> Am Montag, 3. April 2017, 08:10:19 CEST schrieb abed mohammad kamaluddin:
>
> Hi abed,
>
>> Hi Herbert,
>>
>> We have implemented algif acomp interface for user space applications
>> to utilize the kernel compression framework and the hardware drivers
>> using it and have been testing it using userspace zlib library.
>>
>> However, what we find lacking in the existing acomp implementation is
>> the ability to pass context data between the applications and the
>> drivers using the acomp interface. Currently the interface only allows
>> src/dest data  and a flag argument with each request. There are two
>> context pointers, one in acomp_req and another in crypto_tfm but they
>> are for internal use and not available to applications through the
>> api's. Would it be acceptable to add fields that need to be
>> communicated b/w the driver and applications like history,
>> csum/adler32, EOF, stream ctx  to acomp_req.
>>
>> Or is there any other way, which I may have missed, through which we
>> can pass ctx data between applications and drivers while using the
>> kernel compression framework?
>
> If you follow the AF_ALG implementations that are currently in the kernel, a
> calling application receives two file descriptors. The first file descriptor
> is the reference to a tfm, the second is the reference to a particular
> request.
>
> Wouldn't those file descriptors be the reference you are looking for?
>
> Ciao
> Stephan

Re: algif for compression?

[Stephan Müller]

Am Montag, 3. April 2017, 08:10:19 CEST schrieb abed mohammad kamaluddin:

Hi abed,

> Hi Herbert,
> 
> We have implemented algif acomp interface for user space applications
> to utilize the kernel compression framework and the hardware drivers
> using it and have been testing it using userspace zlib library.
> 
> However, what we find lacking in the existing acomp implementation is
> the ability to pass context data between the applications and the
> drivers using the acomp interface. Currently the interface only allows
> src/dest data  and a flag argument with each request. There are two
> context pointers, one in acomp_req and another in crypto_tfm but they
> are for internal use and not available to applications through the
> api's. Would it be acceptable to add fields that need to be
> communicated b/w the driver and applications like history,
> csum/adler32, EOF, stream ctx  to acomp_req.
> 
> Or is there any other way, which I may have missed, through which we
> can pass ctx data between applications and drivers while using the
> kernel compression framework?

If you follow the AF_ALG implementations that are currently in the kernel, a 
calling application receives two file descriptors. The first file descriptor 
is the reference to a tfm, the second is the reference to a particular 
request.

Wouldn't those file descriptors be the reference you are looking for?

Ciao
Stephan

Re: algif for compression?

[abed mohammad kamaluddin]

Hi Herbert,

We have implemented algif acomp interface for user space applications
to utilize the kernel compression framework and the hardware drivers
using it and have been testing it using userspace zlib library.

However, what we find lacking in the existing acomp implementation is
the ability to pass context data between the applications and the
drivers using the acomp interface. Currently the interface only allows
src/dest data  and a flag argument with each request. There are two
context pointers, one in acomp_req and another in crypto_tfm but they
are for internal use and not available to applications through the
api's. Would it be acceptable to add fields that need to be
communicated b/w the driver and applications like history,
csum/adler32, EOF, stream ctx  to acomp_req.

Or is there any other way, which I may have missed, through which we
can pass ctx data between applications and drivers while using the
kernel compression framework?

Thanks,
Abed
(Cavium Inc)


On Sat, Dec 10, 2016 at 1:40 PM, Herbert Xu  wrote:
> abed mohammad kamaluddin  wrote:
>>
>> We are also looking for user-space access to the kernel crypto layer
>> compression algorithms. I have gone through AF_ALG but couldn’t find
>> support for compression ops through it. This is required for our
>> hardware zip engines whose driver hooks up to the crypto layer.
>>
>> I was going through the lists and stumbled across this thread. Has
>> there been  any updates or efforts put up in this direction since this
>> thread is a few years old. If not, are there any alternate
>> implementations that allow user-space access to compression? I have
>> gone through cryptodev and see the same limitation there.
>>
>> Would appreciate any pointers in this regard.
>
> The compression interface is currently in a state of flux.  We
> should make it settle down first before exporting it to user-space.
>
> For a start it would be good to actually switch IPsec/IPcomp over
> to the new compression interface.
>
> Cheers,
> --
> Email: Herbert Xu 
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: algif for compression?

[Herbert Xu]

On Fri, Dec 16, 2016 at 07:41:23PM +0530, abed mohammad kamaluddin wrote:
>
> Thanks Herbert. Are there timelines or  ongoing efforts for moving
> IPcomp/Ipsec to use acomp? Or any proposals that have been or need to
> be taken up in this regard.

Someone needs to write the patches :)
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: algif for compression?

[abed mohammad kamaluddin]

>
> The compression interface is currently in a state of flux.  We
> should make it settle down first before exporting it to user-space.
>
> For a start it would be good to actually switch IPsec/IPcomp over
> to the new compression interface.

Thanks Herbert. Are there timelines or  ongoing efforts for moving
IPcomp/Ipsec to use acomp? Or any proposals that have been or need to
be taken up in this regard.

Thanks,
Abed
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: algif for compression?

[Herbert Xu]

abed mohammad kamaluddin  wrote:
> 
> We are also looking for user-space access to the kernel crypto layer
> compression algorithms. I have gone through AF_ALG but couldn’t find
> support for compression ops through it. This is required for our
> hardware zip engines whose driver hooks up to the crypto layer.
> 
> I was going through the lists and stumbled across this thread. Has
> there been  any updates or efforts put up in this direction since this
> thread is a few years old. If not, are there any alternate
> implementations that allow user-space access to compression? I have
> gone through cryptodev and see the same limitation there.
> 
> Would appreciate any pointers in this regard.

The compression interface is currently in a state of flux.  We
should make it settle down first before exporting it to user-space.

For a start it would be good to actually switch IPsec/IPcomp over
to the new compression interface.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: algif for compression?

[Herbert Xu]

Dan Streetman ddstr...@ieee.org wrote:
 I see the algif_hash and algif_blkcipher implementations to allow
 userspace AF_ALG socket access to kernel blkcipher and hash
 algorithms, but has anyone done a algif_compression to allow userspace
 access to compression algs?  I'm asking specifically wrt the 842
 crypto module, which uses the hardware compression coprocessors on
 newer powerpc systems.
 
 If not, is there any reason against adding a algif_compression to
 provide the access?

For a start nx-842 isn't even hooked into the crypto layer so
there is no chance of exporting it through algif as is.

There is no reason why you couldn't add it of course but that'd
be a first step.

Cheers,
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: algif for compression?

[Dan Streetman]

On Thu, Apr 3, 2014 at 8:41 AM, Herbert Xu herb...@gondor.apana.org.au wrote:
 Dan Streetman ddstr...@ieee.org wrote:
 I see the algif_hash and algif_blkcipher implementations to allow
 userspace AF_ALG socket access to kernel blkcipher and hash
 algorithms, but has anyone done a algif_compression to allow userspace
 access to compression algs?  I'm asking specifically wrt the 842
 crypto module, which uses the hardware compression coprocessors on
 newer powerpc systems.

 If not, is there any reason against adding a algif_compression to
 provide the access?

 For a start nx-842 isn't even hooked into the crypto layer so
 there is no chance of exporting it through algif as is.

Wait, isn't it?  The crypto/842.c driver connects right to it.  Well,
it connects to the compression part of it, but that's the only part
I'm looking at exporting to userspace right now.



 There is no reason why you couldn't add it of course but that'd
 be a first step.

 Cheers,
 --
 Email: Herbert Xu herb...@gondor.apana.org.au
 Home Page: http://gondor.apana.org.au/~herbert/
 PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
 --
 To unsubscribe from this list: send the line unsubscribe linux-crypto in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

algif for compression?

[Dan Streetman]

I see the algif_hash and algif_blkcipher implementations to allow
userspace AF_ALG socket access to kernel blkcipher and hash
algorithms, but has anyone done a algif_compression to allow userspace
access to compression algs?  I'm asking specifically wrt the 842
crypto module, which uses the hardware compression coprocessors on
newer powerpc systems.

If not, is there any reason against adding a algif_compression to
provide the access?

Thanks!
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html