Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

2016-06-03 Thread Baolin Wang
On 3 June 2016 at 18:09, Herbert Xu wrote: > On Fri, Jun 03, 2016 at 05:23:59PM +0800, Baolin Wang wrote: >> >> Assuming one 64K size bio coming, we can map the whole bio with one sg >> table in crypt_convert_bulk_block() function. But if we send this bulk >> request

Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

2016-06-03 Thread Baolin Wang
On 3 June 2016 at 18:09, Herbert Xu wrote: > On Fri, Jun 03, 2016 at 05:23:59PM +0800, Baolin Wang wrote: >> >> Assuming one 64K size bio coming, we can map the whole bio with one sg >> table in crypt_convert_bulk_block() function. But if we send this bulk >> request to crypto layer, we should

Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

2016-06-03 Thread Herbert Xu
On Fri, Jun 03, 2016 at 05:23:59PM +0800, Baolin Wang wrote: > > Assuming one 64K size bio coming, we can map the whole bio with one sg > table in crypt_convert_bulk_block() function. But if we send this bulk > request to crypto layer, we should divide the bulk request into small > requests, and

Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

2016-06-03 Thread Herbert Xu
On Fri, Jun 03, 2016 at 05:23:59PM +0800, Baolin Wang wrote: > > Assuming one 64K size bio coming, we can map the whole bio with one sg > table in crypt_convert_bulk_block() function. But if we send this bulk > request to crypto layer, we should divide the bulk request into small > requests, and

Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

2016-06-03 Thread Baolin Wang
On 3 June 2016 at 16:21, Herbert Xu wrote: > On Fri, Jun 03, 2016 at 04:15:28PM +0800, Baolin Wang wrote: >> >> Suppose the cbc(aes) algorithm, which can not be handled through bulk >> interface, it need to map the data sector by sector. >> If we also handle the

Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

2016-06-03 Thread Baolin Wang
On 3 June 2016 at 16:21, Herbert Xu wrote: > On Fri, Jun 03, 2016 at 04:15:28PM +0800, Baolin Wang wrote: >> >> Suppose the cbc(aes) algorithm, which can not be handled through bulk >> interface, it need to map the data sector by sector. >> If we also handle the cbc(aes) algorithm with bulk

Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

2016-06-03 Thread Herbert Xu
On Fri, Jun 03, 2016 at 04:15:28PM +0800, Baolin Wang wrote: > > Suppose the cbc(aes) algorithm, which can not be handled through bulk > interface, it need to map the data sector by sector. > If we also handle the cbc(aes) algorithm with bulk interface, we need > to divide the sg table into

Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

2016-06-03 Thread Herbert Xu
On Fri, Jun 03, 2016 at 04:15:28PM +0800, Baolin Wang wrote: > > Suppose the cbc(aes) algorithm, which can not be handled through bulk > interface, it need to map the data sector by sector. > If we also handle the cbc(aes) algorithm with bulk interface, we need > to divide the sg table into

Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

2016-06-03 Thread Baolin Wang
On 3 June 2016 at 15:54, Herbert Xu wrote: > On Fri, Jun 03, 2016 at 03:10:31PM +0800, Baolin Wang wrote: >> On 3 June 2016 at 14:51, Herbert Xu wrote: >> > On Fri, Jun 03, 2016 at 02:48:34PM +0800, Baolin Wang wrote: >> >> >> >> If we

Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

2016-06-03 Thread Baolin Wang
On 3 June 2016 at 15:54, Herbert Xu wrote: > On Fri, Jun 03, 2016 at 03:10:31PM +0800, Baolin Wang wrote: >> On 3 June 2016 at 14:51, Herbert Xu wrote: >> > On Fri, Jun 03, 2016 at 02:48:34PM +0800, Baolin Wang wrote: >> >> >> >> If we move the IV generation into the crypto API, we also can not

Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

2016-06-03 Thread Herbert Xu
On Fri, Jun 03, 2016 at 03:10:31PM +0800, Baolin Wang wrote: > On 3 June 2016 at 14:51, Herbert Xu wrote: > > On Fri, Jun 03, 2016 at 02:48:34PM +0800, Baolin Wang wrote: > >> > >> If we move the IV generation into the crypto API, we also can not > >> handle every

Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

2016-06-03 Thread Herbert Xu
On Fri, Jun 03, 2016 at 03:10:31PM +0800, Baolin Wang wrote: > On 3 June 2016 at 14:51, Herbert Xu wrote: > > On Fri, Jun 03, 2016 at 02:48:34PM +0800, Baolin Wang wrote: > >> > >> If we move the IV generation into the crypto API, we also can not > >> handle every algorithm with the bulk

Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

2016-06-03 Thread Baolin Wang
On 3 June 2016 at 14:51, Herbert Xu wrote: > On Fri, Jun 03, 2016 at 02:48:34PM +0800, Baolin Wang wrote: >> >> If we move the IV generation into the crypto API, we also can not >> handle every algorithm with the bulk interface. Cause we also need to >> use different

Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

2016-06-03 Thread Baolin Wang
On 3 June 2016 at 14:51, Herbert Xu wrote: > On Fri, Jun 03, 2016 at 02:48:34PM +0800, Baolin Wang wrote: >> >> If we move the IV generation into the crypto API, we also can not >> handle every algorithm with the bulk interface. Cause we also need to >> use different methods to map one whole bio

Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

2016-06-03 Thread Herbert Xu
On Fri, Jun 03, 2016 at 02:48:34PM +0800, Baolin Wang wrote: > > If we move the IV generation into the crypto API, we also can not > handle every algorithm with the bulk interface. Cause we also need to > use different methods to map one whole bio or map one sector according > to the algorithm

Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

2016-06-03 Thread Herbert Xu
On Fri, Jun 03, 2016 at 02:48:34PM +0800, Baolin Wang wrote: > > If we move the IV generation into the crypto API, we also can not > handle every algorithm with the bulk interface. Cause we also need to > use different methods to map one whole bio or map one sector according > to the algorithm

Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

2016-06-03 Thread Baolin Wang
Hi Herbet, On 2 June 2016 at 16:26, Herbert Xu wrote: > On Fri, May 27, 2016 at 07:11:23PM +0800, Baolin Wang wrote: >> Now some cipher hardware engines prefer to handle bulk block rather than one >> sector (512 bytes) created by dm-crypt, cause these cipher engines

Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

2016-06-03 Thread Baolin Wang
Hi Herbet, On 2 June 2016 at 16:26, Herbert Xu wrote: > On Fri, May 27, 2016 at 07:11:23PM +0800, Baolin Wang wrote: >> Now some cipher hardware engines prefer to handle bulk block rather than one >> sector (512 bytes) created by dm-crypt, cause these cipher engines can handle >> the

Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

2016-06-02 Thread Herbert Xu
On Fri, May 27, 2016 at 07:11:23PM +0800, Baolin Wang wrote: > Now some cipher hardware engines prefer to handle bulk block rather than one > sector (512 bytes) created by dm-crypt, cause these cipher engines can handle > the intermediate values (IV) by themselves in one bulk block. This means we

Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

2016-06-02 Thread Herbert Xu
On Fri, May 27, 2016 at 07:11:23PM +0800, Baolin Wang wrote: > Now some cipher hardware engines prefer to handle bulk block rather than one > sector (512 bytes) created by dm-crypt, cause these cipher engines can handle > the intermediate values (IV) by themselves in one bulk block. This means we

[RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

2016-05-27 Thread Baolin Wang
Now some cipher hardware engines prefer to handle bulk block rather than one sector (512 bytes) created by dm-crypt, cause these cipher engines can handle the intermediate values (IV) by themselves in one bulk block. This means we can increase the size of the request by merging request rather than

[RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

2016-05-27 Thread Baolin Wang
Now some cipher hardware engines prefer to handle bulk block rather than one sector (512 bytes) created by dm-crypt, cause these cipher engines can handle the intermediate values (IV) by themselves in one bulk block. This means we can increase the size of the request by merging request rather than