Re: algif for compression?
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?
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?
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?
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?
> > 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?
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?
Hi, >> 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. 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. Thanks, Abed (Cavium Inc) -- 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?
On Thu, Apr 3, 2014 at 8:41 AM, Herbert Xu wrote: > Dan Streetman 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 > 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
Re: algif for compression?
Dan Streetman 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 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
algif for compression?
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