Re: ipsec impact on performance

[David Ahern]

On 12/1/15 10:17 AM, Rick Jones wrote:

On 12/01/2015 09:59 AM, Sowmini Varadhan wrote:

But these are all still relatively small things - tweaking them
doesnt get me significantly past the 3 Gbps limit. Any suggestions
on how to make this budge (or design criticism of the patch) would
be welcome.


What do the perf profiles show?  Presumably, loss of TSO/GSO means an
increase in the per-packet costs, but if the ipsec path significantly
increases the per-byte costs...

Short of a perf profile, I suppose one way to probe for per-packet
versus per-byte would be to up the MTU.  That should reduce the
per-packet costs while keeping the per-byte roughly the same.


Using iperf3 and AH with NULL algorithm between 2 peers connected by a 
10G link.


Without AH configured I get a steady 9.9 Gbps with iperf3 consuming 
about 55% cpu.


With AH I get ~1.5 Gbps with MTU at 1500:

[  4]   0.00-1.01   sec   160 MBytes  1.33 Gbits/sec   23905 KBytes
[  4]   1.01-2.00   sec   211 MBytes  1.79 Gbits/sec0996 KBytes

iperf3 runs about 60% CPU and ksoftirqd/2 is at 86%.


Bumping the MTU to 9000:

[  4]   3.00-4.00   sec   914 MBytes  7.67 Gbits/sec  260   1.01 MBytes
[  4]   4.00-5.00   sec  1012 MBytes  8.49 Gbits/sec0   1.23 MBytes
[  4]   5.00-6.00   sec  1.15 GBytes  9.88 Gbits/sec0   1.23 MBytes

At this rate iperf3 was at 95% CPU and ksoftirqd was not relevant.
--
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: ipsec impact on performance

[Sowmini Varadhan]

On (12/01/15 16:56), David Ahern wrote:
> 
> Using iperf3 and AH with NULL algorithm between 2 peers connected by
> a 10G link.
> 
I'm using esp-null, not AH, and iperf2, which I understand is 
quite different from, and more aggressive than, iperf3 (though I'm not 
sure that it matters for this single-stream case).

> With AH I get ~1.5 Gbps with MTU at 1500:

But yes, I get approx that too. 

The "good" news is that I can get about 3 Gbps with my patch. So one
could say that I've 2x-ed the perf. Except that:

The "bad" news is that even GSO/GRO can do way better, so we
need to be able to extend that perf to also be available 
to some key TCP and IP extensions (like md5 and ipsec, maybe)
and beyond (i.e need to de-ossify the stack so we can extend
TCP/IP features without sacrificing perf along the way).

The not-so-great news is that I see that just adding perf tracepoints
(not even enabling them!) seems to make a small diff (3 Gbps vs 3.2 Gbps) 
to my numbers. Is that mere standard-deviation, or something 
one should be aware of, about perf?

> iperf3 runs about 60% CPU and ksoftirqd/2 is at 86%.

yes, not surprising. You really need to compare this to GSO/GRO
for a pure-s/w,  apples-apples comparison.

> Bumping the MTU to 9000:

Yes that's not always an option. See also the comments from Eric/Rick
about latency [http://lists.openwall.net/netdev/2015/11/24/111]. 

--Sowmini
--
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: ipsec impact on performance

[David Ahern]

On 12/1/15 5:09 PM, Sowmini Varadhan wrote:

The not-so-great news is that I see that just adding perf tracepoints
(not even enabling them!) seems to make a small diff (3 Gbps vs 3.2 Gbps)
to my numbers. Is that mere standard-deviation, or something
one should be aware of, about perf?


existence of traepoints has no overhead until activated (ie., launch 
perf or start ftrace for those tracepoints).

--
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: [PATCH v3 5/5] crypto: AES CBC multi-buffer glue code

[Tim Chen]

On Thu, 2015-11-26 at 16:49 +0800, Herbert Xu wrote:
> On Tue, Nov 24, 2015 at 10:30:06AM -0800, Tim Chen wrote:
> >
> > On the decrypt path, we don't need to use multi-buffer algorithm
> > as aes-cbc decrypt can be parallelized inherently on a single
> > request.  So most of the time the outer layer algorithm
> > cbc_mb_async_ablk_decrypt can bypass mcryptd and
> > invoke mb_aes_cbc_decrypt synchronously
> > to do aes_cbc_dec when fpu is available.
> > This avoids the overhead of going through mcryptd.  Hence
> > the use of blkcipher on the inner layer.  For the mcryptd
> > path, we will complete a decrypt request in one shot so
> > blkcipher usage should be fine.
> 
> I think there is a misunderstanding here.  Just because you're
> using/exporting through the ablkcipher interface doesn't mean
> that you are asynchrounous.  For example, all blkcipher algorithms
> can be accessed through the ablkcipher interface and they of course
> remain synchrounous.
> 
> So I don't see how using an ablkcipher in the inner layer changes
> anything at all.  You can still return immediately and not bother
> with completion functions when you are synchrounous.
> 
> Cheers,

OK, I'll try to see if I can cast things back to the original ablkcipher
request and use that to walk the sg list.

Tim

--
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

ipsec impact on performance

[Sowmini Varadhan]

I instrumented iperf with and without ipsec, just using esp-null, 
and 1 thread, to keep things simple. I'm seeing some pretty dismal 
performance numbers with ipsec, and trying to think of ways to
improve this. Here are my findings, please share feedback.

I suspect that a big part of the problem is the implicit loss of GSO,
and this is made worse by some inefficiencies in the xfrm code:
for single stream iperf (to avoid effects of rx-hash), I see the
following on a 10G p2p ethernet link.
 8.5-9.5 Gbps clear traffic, TSO disabled, so GSO, GRO is in effect
 3-4 Gbps clear traffic, with both TSO/GSO disabled
 1.8-2 Gbps for esp-null.
So the above numbers suggest that losing TSO/GSO results in one
big drop in performance, and then there's another cliff for the 
clear -> esp-null transition. And those cliffs apply even if you are
merely doing TCP-MD5 or AO for basic protection of the TCP connection.

I tried moving things about a bit to defer the ipsec after GSO - I'll 
share my experimental patch as an RFC in a separate thread. (Disclaimer:
the patch is just an experiment at this point).

In that patch, I'm only focussing on esp-null and transp-mode ipsec
for now, just to get some basic performance numbers to see if this is 
at all interesting.  Essentially my hack mainly involves the following

- don't disable TSO in sk_setup_caps() if a dst->header_len is found
- in xfrm4_output, if GSO is applicable, bail out without esp header 
  addition - that will get done after skb_segment()
- at the end of tcp_gso_segment() (when tcp segment is available),
  set things up for xfrm_output_one and trigger the esp_output..
  I have to be very careful about setting up skb pointers here, since
  it looks like esp_output overloads the mac_header pointer e.g., for
  setting up the ip protocol field 

If I do all these things, the ipsec+iperf improves slightly- for
esp-null, I move from approx 1.8 Gbps  to about 3 Gbps, but clearly,
this is still quite far from the 8 - 9 Gbps that I can get with just
GSO+GRO for non-ipsec traffic.

There are some inefficiencies that I can see in the xfrm code,
that I am inheriting in my patch, e.g.,:
  memory management in the xfrm code has room for improvement. Every
  pass through xfrm_transport_output ends up doing a (avoidable?) memmove,
  and each pass through esp_output ends up doing a kmalloc/free of the
  "tmp" buffer. 
But these are all still relatively small things - tweaking them 
doesnt get me significantly past the 3 Gbps limit. Any suggestions
on how to make this budge (or design criticism of the patch) would
be welcome.

--Sowmini

--
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: ipsec impact on performance

[Tom Herbert]

On Tue, Dec 1, 2015 at 9:59 AM, Sowmini Varadhan
 wrote:
>
> I instrumented iperf with and without ipsec, just using esp-null,
> and 1 thread, to keep things simple. I'm seeing some pretty dismal
> performance numbers with ipsec, and trying to think of ways to
> improve this. Here are my findings, please share feedback.
>
> I suspect that a big part of the problem is the implicit loss of GSO,
> and this is made worse by some inefficiencies in the xfrm code:
> for single stream iperf (to avoid effects of rx-hash), I see the
> following on a 10G p2p ethernet link.
>  8.5-9.5 Gbps clear traffic, TSO disabled, so GSO, GRO is in effect
>  3-4 Gbps clear traffic, with both TSO/GSO disabled
>  1.8-2 Gbps for esp-null.

Are you losing checksum offload also?

> So the above numbers suggest that losing TSO/GSO results in one
> big drop in performance, and then there's another cliff for the
> clear -> esp-null transition. And those cliffs apply even if you are
> merely doing TCP-MD5 or AO for basic protection of the TCP connection.
>
> I tried moving things about a bit to defer the ipsec after GSO - I'll
> share my experimental patch as an RFC in a separate thread. (Disclaimer:
> the patch is just an experiment at this point).
>
> In that patch, I'm only focussing on esp-null and transp-mode ipsec
> for now, just to get some basic performance numbers to see if this is
> at all interesting.  Essentially my hack mainly involves the following
>
> - don't disable TSO in sk_setup_caps() if a dst->header_len is found
> - in xfrm4_output, if GSO is applicable, bail out without esp header
>   addition - that will get done after skb_segment()
> - at the end of tcp_gso_segment() (when tcp segment is available),
>   set things up for xfrm_output_one and trigger the esp_output..
>   I have to be very careful about setting up skb pointers here, since
>   it looks like esp_output overloads the mac_header pointer e.g., for
>   setting up the ip protocol field
>
> If I do all these things, the ipsec+iperf improves slightly- for
> esp-null, I move from approx 1.8 Gbps  to about 3 Gbps, but clearly,
> this is still quite far from the 8 - 9 Gbps that I can get with just
> GSO+GRO for non-ipsec traffic.
>
> There are some inefficiencies that I can see in the xfrm code,
> that I am inheriting in my patch, e.g.,:
>   memory management in the xfrm code has room for improvement. Every
>   pass through xfrm_transport_output ends up doing a (avoidable?) memmove,
>   and each pass through esp_output ends up doing a kmalloc/free of the
>   "tmp" buffer.
> But these are all still relatively small things - tweaking them
> doesnt get me significantly past the 3 Gbps limit. Any suggestions
> on how to make this budge (or design criticism of the patch) would
> be welcome.
>
Thanks for the nice data! We could certainly implement GRO/GSO for
esp-null to get your numbers up but I don't think that would be very
useful to anyone. Do you have the performance numbers using real
encryption?

> --Sowmini
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" 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: ipsec impact on performance

[Rick Jones]

On 12/01/2015 09:59 AM, Sowmini Varadhan wrote:

But these are all still relatively small things - tweaking them
doesnt get me significantly past the 3 Gbps limit. Any suggestions
on how to make this budge (or design criticism of the patch) would
be welcome.


What do the perf profiles show?  Presumably, loss of TSO/GSO means an 
increase in the per-packet costs, but if the ipsec path significantly 
increases the per-byte costs...


Short of a perf profile, I suppose one way to probe for per-packet 
versus per-byte would be to up the MTU.  That should reduce the 
per-packet costs while keeping the per-byte roughly the same.


You could also compare the likes of a single-byte netperf TCP_RR test 
between ipsec enabled and not to get an idea of the basic path length 
differences without TSO/GSO/whatnot muddying the waters.


happy benchmarking,

rick jones
--
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: ipsec impact on performance

[Steffen Klassert]

On Tue, Dec 01, 2015 at 12:59:53PM -0500, Sowmini Varadhan wrote:
> 
> I instrumented iperf with and without ipsec, just using esp-null, 
> and 1 thread, to keep things simple. I'm seeing some pretty dismal 
> performance numbers with ipsec, and trying to think of ways to
> improve this. Here are my findings, please share feedback.
> 
> I suspect that a big part of the problem is the implicit loss of GSO,
> and this is made worse by some inefficiencies in the xfrm code:
> for single stream iperf (to avoid effects of rx-hash), I see the
> following on a 10G p2p ethernet link.
>  8.5-9.5 Gbps clear traffic, TSO disabled, so GSO, GRO is in effect
>  3-4 Gbps clear traffic, with both TSO/GSO disabled
>  1.8-2 Gbps for esp-null.
> So the above numbers suggest that losing TSO/GSO results in one
> big drop in performance, and then there's another cliff for the 
> clear -> esp-null transition. And those cliffs apply even if you are
> merely doing TCP-MD5 or AO for basic protection of the TCP connection.
> 
> I tried moving things about a bit to defer the ipsec after GSO - I'll 
> share my experimental patch as an RFC in a separate thread. (Disclaimer:
> the patch is just an experiment at this point).
> 
> In that patch, I'm only focussing on esp-null and transp-mode ipsec
> for now, just to get some basic performance numbers to see if this is 
> at all interesting.  Essentially my hack mainly involves the following
> 
> - don't disable TSO in sk_setup_caps() if a dst->header_len is found
> - in xfrm4_output, if GSO is applicable, bail out without esp header 
>   addition - that will get done after skb_segment()
> - at the end of tcp_gso_segment() (when tcp segment is available),
>   set things up for xfrm_output_one and trigger the esp_output..
>   I have to be very careful about setting up skb pointers here, since
>   it looks like esp_output overloads the mac_header pointer e.g., for
>   setting up the ip protocol field 

I'm currently working on a GRO/GSO codepath for IPsec too. The GRO part
works already. I decapsulate/decrypt the packets on layer2 with a esp GRO
callback function and reinject them into napi_gro_receive(). So in case
the decapsulated packet is TCP, GRO can aggregate big packets.

My approach to GSO is a bit different to yours. I focused on tunnel mode,
but transport mode should work too. I encapsulate the big GSO packets
but don't do the encryption. Then I've added a esp_gso_segment() function,
so the (still not encrypted ESP packets) get segmented with GSO. Finally I
do encryption for all segments. This works well as long as I do sync crypto.
The hard part is when crypto returns async. This is what I'm working on now.
I hope to get this ready during the next weeks that I can post a RFC version
and some numbers.

Also I tried to consider the IPsec GRO/GSO codepath as a software fallback.
So I added hooks for the encapsulation, encryption etc. If a NIC can do
IPsec, it can use this hooks to prepare the packets the way it needs it.
There are NICs that can do IPsec, it's just that our stack does not support
it.

Another thing, I thought about setting up an IPsec BoF/workshop at
netdev1.1. My main topic is GRO/GSO for IPsec. I'll send out a mail
to the list later this week to see if there is enough interest and
maybe some additional topics.

--
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: ipsec impact on performance

[Sowmini Varadhan]

On (12/01/15 10:17), Rick Jones wrote:
> 
> What do the perf profiles show?  Presumably, loss of TSO/GSO means
> an increase in the per-packet costs, but if the ipsec path
> significantly increases the per-byte costs...

For ESP-null, there's actually very little work to do - we just
need to add the 8 byte ESP header with an spi and a seq#.. no
crypto work to do.. so the overhead *should* be minimal, else
we've painted ourself into a corner where we can't touch anything
including TCP options like md5.

perf profiles: I used perf tracepoints to instrument latency.
Yes, there is function call overhead for the xfrm path. So, for example,
the stack ends up being like this:
  :
  e5d2f2 ip_finish_output ([kerne.kallsyms])
  75d6d0 ip_output ([kernel.kallsyms])
  7c08ad xfrm_output_resume ([kernel.kallsyms])
  7c0aae xfrm_output ([kernel.kallsyms])
  7b1bdd xfrm4_output_finish ([kernel.kallsyms])
  7b1c7e __xfrm4_output ([kernel.kallsyms])
  7b1dbe xfrm4_output ([kernel.kallsyms])
  75bac4 ip_local_out ([kernel.kallsyms])
  75c012 ip_queue_xmit ([kernel.kallsyms])
  7736a3 tcp_transmit_skb ([kernel.kallsyms])
  :
where the detour into xfrm has been indented out, and esp_output
gets called out of xfrm_output_resume(). And as I said, there's
some nickels-and-dimes of perf to be squeezed out from 
better memory management in xfrm, but the fact that it doesnt move
beyond 3 Gbps strikes me as some other bottleneck/serialization.

> Short of a perf profile, I suppose one way to probe for per-packet
> versus per-byte would be to up the MTU.  That should reduce the
> per-packet costs while keeping the per-byte roughly the same.

actually the hack/rfc I sent out does help (in that it almost
doubles the existing 1.8 Gbps). Problem is that this cliff is much
steeper than that, and there's more hidden somewhere.

--Sowmini
--
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: ipsec impact on performance

[Sowmini Varadhan]

On (12/01/15 10:18), Tom Herbert wrote:
> >  8.5-9.5 Gbps clear traffic, TSO disabled, so GSO, GRO is in effect
> >  3-4 Gbps clear traffic, with both TSO/GSO disabled
> >  1.8-2 Gbps for esp-null.
> 
> Are you losing checksum offload also?

I tried with both checksum offload on and off.
For the GSO case, doesnt make a huge difference to perf. 
For my patch, I disable h/w cksum offload, so that I can leverage
from the existing cksum calculations in the existing GSO code. That helps
a bit (goes from 3 Gbps -> 3.2 Gbps, but I need a 2x jump here)


> Thanks for the nice data! We could certainly implement GRO/GSO for
> esp-null to get your numbers up but I don't think that would be very
> useful to anyone. Do you have the performance numbers using real
> encryption?

I was using esp-null merely to not have the crypto itself perturb
the numbers (i.e., just focus on the s/w overhead for now), but here
are the numbers for the stock linux kernel stack
Gbps  peak cpu util
esp-null 1.8   71%
aes-gcm-c-2561.6   79%
aes-ccm-a-1280.7   96%

That trend made me think that if we can get esp-null to be as close
as possible to GSO/GRO, the rest will follow closely behind.

So is my patch in the right direction? Anything obvious I am missing?
I'd like to budge that number beyond 3 Gbps :-)

--Sowmini
--
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: ipsec impact on performance

[Rick Jones]

On 12/01/2015 10:45 AM, Sowmini Varadhan wrote:

On (12/01/15 10:17), Rick Jones wrote:


What do the perf profiles show?  Presumably, loss of TSO/GSO means
an increase in the per-packet costs, but if the ipsec path
significantly increases the per-byte costs...


For ESP-null, there's actually very little work to do - we just
need to add the 8 byte ESP header with an spi and a seq#.. no
crypto work to do.. so the overhead *should* be minimal, else
we've painted ourself into a corner where we can't touch anything
including TCP options like md5.


Something of a longshot, but are you sure you are still getting 
effective CKO/GRO on the receiver?


rick jones
--
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: ipsec impact on performance

[Sowmini Varadhan]

On (12/01/15 10:50), Rick Jones wrote:
> 
> Something of a longshot, but are you sure you are still getting
> effective CKO/GRO on the receiver?

Good question. With ipsec, GRO (like GSO) gets implicitly disabled.

But when I explictly disable GRO on receiver, leaving only GSO
on sender, I can still get about 6 Gbps for clear traffic.

Thus if I could get closer to 6 Gbps for my patch, I'd at least
know that it was just GRO that was missing.. but I'm only getting 
3 Gbps, which makes me think I missed something else on the sender
itself.

--Sowmini

--
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

[PATCH] crypto: talitos - add new crypto modes

[Christophe Leroy]

This patch adds the following algorithms to the talitos driver:
* ecb(aes)
* ctr(aes)
* ecb(des)
* cbc(des)
* ecb(des3_ede)

Signed-off-by: Christophe Leroy 
---
 drivers/crypto/talitos.c | 83 
 drivers/crypto/talitos.h |  1 +
 2 files changed, 84 insertions(+)

diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index ab33898..a0d4a08 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -2324,6 +2324,22 @@ static struct talitos_alg_template driver_algs[] = {
/* ABLKCIPHER algorithms. */
{   .type = CRYPTO_ALG_TYPE_ABLKCIPHER,
.alg.crypto = {
+   .cra_name = "ecb(aes)",
+   .cra_driver_name = "ecb-aes-talitos",
+   .cra_blocksize = AES_BLOCK_SIZE,
+   .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+CRYPTO_ALG_ASYNC,
+   .cra_ablkcipher = {
+   .min_keysize = AES_MIN_KEY_SIZE,
+   .max_keysize = AES_MAX_KEY_SIZE,
+   .ivsize = AES_BLOCK_SIZE,
+   }
+   },
+   .desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU |
+DESC_HDR_SEL0_AESU,
+   },
+   {   .type = CRYPTO_ALG_TYPE_ABLKCIPHER,
+   .alg.crypto = {
.cra_name = "cbc(aes)",
.cra_driver_name = "cbc-aes-talitos",
.cra_blocksize = AES_BLOCK_SIZE,
@@ -2341,6 +2357,73 @@ static struct talitos_alg_template driver_algs[] = {
},
{   .type = CRYPTO_ALG_TYPE_ABLKCIPHER,
.alg.crypto = {
+   .cra_name = "ctr(aes)",
+   .cra_driver_name = "ctr-aes-talitos",
+   .cra_blocksize = AES_BLOCK_SIZE,
+   .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+CRYPTO_ALG_ASYNC,
+   .cra_ablkcipher = {
+   .min_keysize = AES_MIN_KEY_SIZE,
+   .max_keysize = AES_MAX_KEY_SIZE,
+   .ivsize = AES_BLOCK_SIZE,
+   }
+   },
+   .desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU |
+DESC_HDR_SEL0_AESU |
+DESC_HDR_MODE0_AESU_CTR,
+   },
+   {   .type = CRYPTO_ALG_TYPE_ABLKCIPHER,
+   .alg.crypto = {
+   .cra_name = "ecb(des)",
+   .cra_driver_name = "ecb-des-talitos",
+   .cra_blocksize = DES_BLOCK_SIZE,
+   .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+CRYPTO_ALG_ASYNC,
+   .cra_ablkcipher = {
+   .min_keysize = DES_KEY_SIZE,
+   .max_keysize = DES_KEY_SIZE,
+   .ivsize = DES_BLOCK_SIZE,
+   }
+   },
+   .desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU |
+DESC_HDR_SEL0_DEU,
+   },
+   {   .type = CRYPTO_ALG_TYPE_ABLKCIPHER,
+   .alg.crypto = {
+   .cra_name = "cbc(des)",
+   .cra_driver_name = "cbc-des-talitos",
+   .cra_blocksize = DES_BLOCK_SIZE,
+   .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+CRYPTO_ALG_ASYNC,
+   .cra_ablkcipher = {
+   .min_keysize = DES_KEY_SIZE,
+   .max_keysize = DES_KEY_SIZE,
+   .ivsize = DES_BLOCK_SIZE,
+   }
+   },
+   .desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU |
+DESC_HDR_SEL0_DEU |
+DESC_HDR_MODE0_DEU_CBC,
+   },
+   {   .type = CRYPTO_ALG_TYPE_ABLKCIPHER,
+   .alg.crypto = {
+   .cra_name = "ecb(des3_ede)",
+   .cra_driver_name = "ecb-3des-talitos",
+   .cra_blocksize = DES3_EDE_BLOCK_SIZE,
+   .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+CRYPTO_ALG_ASYNC,
+   .cra_ablkcipher = {
+   .min_keysize = DES3_EDE_KEY_SIZE,
+   .max_keysize = DES3_EDE_KEY_SIZE,
+   .ivsize = DES3_EDE_BLOCK_SIZE,
+   }
+   },
+   .desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU |
+