[crypto] [marvell-cesa] Possible regression after Linux 4.7

[crypto] [marvell-cesa] Possible regression after Linux 4.7

[radioconfusion at gmail.com]

Hello,

Thu, 3 Nov 2016 14:57:06 +0100, Romain Perier wrote:
>
> > Do you have any improvement for the issue?
> > Please let me know if you need any help to resolve it.
> >
> > Best Regards,
> > Jussi
> >
>
> Sorry for the delay.
> Could you try to revert locally commit
> 2786cee8e50bb4b4303dc22665f391b72318fa84 (crypto: marvell - Move SRAM
> I/O operations to step functions) ?
>
> It seems to fix most of the issues I had with curl.
> I will continue to investigate, that's just to confirm if it fixes the
> issues for you.
>

Thanks for this suggestion.
Unfortunately, I didn't get improvements using curl with this revertion.

Thanks for your investigation. Waiting for your input.

Best Regards,
Jussi

[crypto] [marvell-cesa] Possible regression after Linux 4.7

[radioconfusion at gmail.com]

Hello,
Fri, 09 Sep 2016 10:24:50 +0300, radioconfusion at gmail.com wrote:
> Thu,  8 Sep 2016 16:52:16 +0200, Romain Perier wrote:
> > > Hello,
> > >
> > > I'm testing the marvell-cesa -driver on Armada 385 board and I think I've found
> > > a regression between Linux 4.7 and 4.8-rc4.
> > > I want to accelerate my curl connections. So I compiled the 4.8-rc4 with
> > > marvell-cesa enabled and HEAD revision of cryptodev-linux.
> > >
> > > Here is my output:
> > >
> > > ~# uname -r
> > > 4.8.0-rc4
> > > ~# modprobe cryptodev
> > > ~# modprobe marvell-cesa
> > > ~# curl -k --ciphers AES256-SHA256 https://myserver/myfile >/dev/null
> > >    % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
> > >                                   Dload  Upload   Total   Spent    Left  Speed
> > >   19  200M   19 39.7M    0     0  16.2M      0  0:00:12  0:00:02  0:00:10 16.2M
> > > curl: (56) SSL read: error:1408F119:SSL routines:SSL3_GET_RECORD:decryption
> > > failed or bad record mac, errno 0
> > >
> --- snip ---
> >
> > Thank you for your feedbacks.
> > I can reproduce the issue with and without multiple engines.

I can still reproduce the issue with Linux 4.9-rc3 (2a26d99b251b8625d27aed14e97fc10707a3a81f)

> > However, I have found an interesting thing, If I use only --ciphers
> > AES256, it works perfectly fine, could you confirm this ?
>
> Yes, I can confirm. And I have found the reason too.
> Most of available ciphers will not be accelerated at all.
> Only these ones I have verified to be accelerated by cesa:
> AES256-SHA256
> AES256-SHA
> AES128-SHA256
> AES128-SHA
>
> When cesa is working, I can see "irq/42-f1090000" on process list of top(1) and
> curl doesn't take all of available cpu.
>
--- snip ---

> > In any case, I will investigate.

Do you have any improvement for the issue?
Please let me know if you need any help to resolve it.

Best Regards,
Jussi

[crypto] [marvell-cesa] Possible regression after Linux 4.7

[Romain Perier]

Hello,

Le 31/10/2016 ? 14:59, radioconfusion at gmail.com a ?crit :

> Do you have any improvement for the issue?
> Please let me know if you need any help to resolve it.
>
> Best Regards,
> Jussi
>

Sorry for the delay.
Could you try to revert locally commit 
2786cee8e50bb4b4303dc22665f391b72318fa84 (crypto: marvell - Move SRAM 
I/O operations to step functions) ?

It seems to fix most of the issues I had with curl.
I will continue to investigate, that's just to confirm if it fixes the 
issues for you.

Thanks,
Romain
-- 
Romain Perier, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[crypto] [marvell-cesa] Possible regression after Linux 4.7

[Romain Perier]

Hello,

The issue is reproducible in STD mode too. We have found fixes.
Could you test these patches in STD mode please ?


cover letter: 
https://www.mail-archive.com/linux-crypto at vger.kernel.org/msg22143.html
1/2: https://www.mail-archive.com/linux-crypto at vger.kernel.org/msg22142.html
2/2: https://www.mail-archive.com/linux-crypto at vger.kernel.org/msg22141.html

If you want to turn off DMA, open drivers/crypto/marvell/cesa.c and in 
armada_xp_caps, change .has_tdma to false.  (assuming that you test on a 
armada 38x).

We're still investigating for regressions in DMA mode.

Have a nice day,
Romain

-- 
Romain Perier, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[crypto] [marvell-cesa] Possible regression after Linux 4.7

[radioconfusion at gmail.com]

Hello,
Thu,  8 Sep 2016 16:52:16 +0200, Romain Perier wrote:
> > Hello,
> >
> > I'm testing the marvell-cesa -driver on Armada 385 board and I think I've found
> > a regression between Linux 4.7 and 4.8-rc4.
> > I want to accelerate my curl connections. So I compiled the 4.8-rc4 with
> > marvell-cesa enabled and HEAD revision of cryptodev-linux.
> >
> > Here is my output:
> >
> > ~# uname -r
> > 4.8.0-rc4
> > ~# modprobe cryptodev
> > ~# modprobe marvell-cesa
> > ~# curl -k --ciphers AES256-SHA256 https://myserver/myfile >/dev/null
> >    % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
> >                                   Dload  Upload   Total   Spent    Left  Speed
> >   19  200M   19 39.7M    0     0  16.2M      0  0:00:12  0:00:02  0:00:10 16.2M
> > curl: (56) SSL read: error:1408F119:SSL routines:SSL3_GET_RECORD:decryption
> > failed or bad record mac, errno 0
> >
--- snip ---
>
> Thank you for your feedbacks.
> I can reproduce the issue with and without multiple engines.

Thank you for your testing. Do you mean that you can reproduce it with
Linux 4.7 too?

> However, I have found an interesting thing, If I use only --ciphers
> AES256, it works perfectly fine, could you confirm this ?

Yes, I can confirm. And I have found the reason too.
Most of available ciphers will not be accelerated at all.
Only these ones I have verified to be accelerated by cesa:
AES256-SHA256
AES256-SHA
AES128-SHA256
AES128-SHA

When cesa is working, I can see "irq/42-f1090000" on process list of top(1) and
curl doesn't take all of available cpu.

It's not easy to detect acceleration by performance because I tested with
Linux 4.7 and older cryptodev (1.8 release) and I got average curl throughput
~22 MiB/s with AES256-SHA256 + cesa. Without cesa I got ~20 MiB/s average with
same configuration.

> In any case, I will investigate.

Thank you very much.

Best Regards,
Jussi

[crypto] [marvell-cesa] Possible regression after Linux 4.7

[radioconfusion at gmail.com]

Hello,

I'm testing the marvell-cesa -driver on Armada 385 board and I think I've found
a regression between Linux 4.7 and 4.8-rc4.
I want to accelerate my curl connections. So I compiled the 4.8-rc4 with
marvell-cesa enabled and HEAD revision of cryptodev-linux.

Here is my output:

~# uname -r
4.8.0-rc4
~# modprobe cryptodev
~# modprobe marvell-cesa
~# curl -k --ciphers AES256-SHA256 https://myserver/myfile >/dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
 19  200M   19 39.7M    0     0  16.2M      0  0:00:12  0:00:02  0:00:10 16.2M
curl: (56) SSL read: error:1408F119:SSL routines:SSL3_GET_RECORD:decryption
failed or bad record mac, errno 0

This error is quite easy to reproduce. Especially if you have some other
connections open at same time or two simultaneous curl-connections.
I had a ssh-connection running top(1).

I can not reproduce this with Linux 4.7 or without modprobing marvell-cesa.

I'm not using any special kernel parameter, patches, custom dts, etc.

Best Regards,
Jussi

[crypto] [marvell-cesa] Possible regression after Linux 4.7

[Romain Perier]

Hello,

Le 06/09/2016 07:27, radioconfusion at gmail.com a ?crit :
> Hello,
>
> I'm testing the marvell-cesa -driver on Armada 385 board and I think I've found
> a regression between Linux 4.7 and 4.8-rc4.
> I want to accelerate my curl connections. So I compiled the 4.8-rc4 with
> marvell-cesa enabled and HEAD revision of cryptodev-linux.
>
> Here is my output:
>
> ~# uname -r
> 4.8.0-rc4
> ~# modprobe cryptodev
> ~# modprobe marvell-cesa
> ~# curl -k --ciphers AES256-SHA256 https://myserver/myfile >/dev/null
>    % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
>                                   Dload  Upload   Total   Spent    Left  Speed
>   19  200M   19 39.7M    0     0  16.2M      0  0:00:12  0:00:02  0:00:10 16.2M
> curl: (56) SSL read: error:1408F119:SSL routines:SSL3_GET_RECORD:decryption
> failed or bad record mac, errno 0
>
> This error is quite easy to reproduce. Especially if you have some other
> connections open at same time or two simultaneous curl-connections.
> I had a ssh-connection running top(1).
>
> I can not reproduce this with Linux 4.7 or without modprobing marvell-cesa.
>
> I'm not using any special kernel parameter, patches, custom dts, etc.
>
> Best Regards,
> Jussi
>

Thank you for your feedbacks.
I can reproduce the issue with and without multiple engines. With the 
following steps:

1. open an ssh connection on the target, and start the following command:

#  while true; do curl -k -v --ciphers AES256-SHA256 https://foobar 
 >/dev/null > /dev/null; done


2. From the uart :
# curl -k --ciphers AES256-SHA256 https://foobar >/dev/null

Then, the second command will fail easily.

However, I have found an interesting thing, If I use only --ciphers 
AES256, it works perfectly fine, could you confirm this ?

In any case, I will investigate.

Thanks!
Romain
-- 
Romain Perier, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com