On Thu, Apr 09, 2009 at 11:20:45AM +0800, Herbert Xu wrote:
You can allocate eseqiv(alg), e.g., eseqiv(cbc(aes)).
Ok, that's possible. I missed this possibility, probaply because nobody
is actually doing it this way. Thanks!
Unfortunately eseqiv does not work out of the box if we do
On Wed, Apr 08, 2009 at 01:40:14PM +0200, Steffen Klassert wrote:
Actually I'm instantiate a crypto_nivaead_type algorithm and choose for
cpu_chainiv as the IV generator for that algorithm. If I want to do the
same with eseqiv it would require to add aead support to eseqiv.
Is this what you
On Fri, Mar 27, 2009 at 04:36:15PM +0800, Herbert Xu wrote:
On Mon, Mar 16, 2009 at 12:52:51PM +0100, Steffen Klassert wrote:
If the crypro requests of a crypto transformation are processed in
parallel, the usual chain IV generator would serialize the crypto
requests again. The percpu IV
On Mon, Mar 30, 2009 at 01:54:15PM +0200, Steffen Klassert wrote:
Well, to do efficient parallel processing we need a percpu IV chain
genarator. pcrypt sends the crypto requests round robin to the cpus
independent of the flow they are belong to, so the flows and the IV
streams are mixing. As
On Mon, Mar 30, 2009 at 09:19:55PM +0800, Herbert Xu wrote:
How about using eseqiv? It's designed for exactly this situation
where you want parallel async processing. Its overhead is just
one extra encryption block.
Yes, that's an option too. I'll give it a try.
Thanks!
--
To unsubscribe
On Mon, Mar 16, 2009 at 12:52:51PM +0100, Steffen Klassert wrote:
If the crypro requests of a crypto transformation are processed in
parallel, the usual chain IV generator would serialize the crypto
requests again. The percpu IV chain genarator allocates the IV as
percpu data and generates
If the crypro requests of a crypto transformation are processed in
parallel, the usual chain IV generator would serialize the crypto
requests again. The percpu IV chain genarator allocates the IV as
percpu data and generates percpu IV chains, so a crypro request
does not need to wait for the
