Re: [ptxdist] [RFC/PATCH 0/3] cryptodev
On Mon, Jul 10, 2017 at 04:11:20PM +0200, Ladislav Michl wrote: > On Mon, Jul 03, 2017 at 08:56:42AM +0200, Robert Schwebel wrote: > > On Mon, Jul 03, 2017 at 12:03:26AM +0200, Alexander Dahl wrote: > > > On Sun, Jul 02, 2017 at 10:30:30PM +0200, Clemens Gruber wrote: > > > > I am wondering about the performance improvements when using the > > > > cryptodev openssl engine. There must be some cost for the context > > > > switches, but this is probably outweighed by the offloading. > > > > Did you for example run openssl speed aes-128-cbc before and after? > > > > And on what platform did you try it? > > > > > > fli4l [1] uses cryptodev and the experience there is, it depends on > > > the platform. Some platforms benefit a lot, especially for OpenVPN, > > > others not so much. Depends on what the CPU offers and how fast the > > > system in general is. > > > > Do you know why the module is not in mainline? Is there a discussion > > where the kernel maintainers motivate why they don't like this solution? > > The module itself is 10+ years old and it is highly unlikely it will be > ever merged as it uses ioctl approach - makes API compatible with OpenBSD. > Meawhile AF_ALG API was introduced without anyone really interested (people > are still using /dev/crypto). Also see this comparsion: > http://cryptodev-linux.org/comparison.html I'm not concerned about upstream, but keeping it up to date in PTXdist. As long as it's not in the mainline kernel, we have a separate packages that needs to be maintained. Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [RFC/PATCH 0/3] cryptodev
On Sun, Jul 02, 2017 at 10:30:30PM +0200, Clemens Gruber wrote: > I am wondering about the performance improvements when using the > cryptodev openssl engine. There must be some cost for the context > switches, but this is probably outweighed by the offloading. > Did you for example run openssl speed aes-128-cbc before and after? > And on what platform did you try it? The cost of the context switches is notable only for small payloads, bigger payload makes hw acceleration more usefull. Bellow is openssl speed test result as run on IGEPv2 board with DM3730 (OMAP3630) - second line is using cryptodev engine (omap-aes 480c5000.aes: OMAP AES hw accel rev: 2.6): The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 25210.41k32946.13k35359.47k36149.68k36203.09k aes-128-cbc 8821.87k55293.26k34594.13k 308582.40k infk ladis ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [RFC/PATCH 0/3] cryptodev
On Mon, Jul 03, 2017 at 08:56:42AM +0200, Robert Schwebel wrote: > On Mon, Jul 03, 2017 at 12:03:26AM +0200, Alexander Dahl wrote: > > On Sun, Jul 02, 2017 at 10:30:30PM +0200, Clemens Gruber wrote: > > > I am wondering about the performance improvements when using the > > > cryptodev openssl engine. There must be some cost for the context > > > switches, but this is probably outweighed by the offloading. > > > Did you for example run openssl speed aes-128-cbc before and after? > > > And on what platform did you try it? > > > > fli4l [1] uses cryptodev and the experience there is, it depends on > > the platform. Some platforms benefit a lot, especially for OpenVPN, > > others not so much. Depends on what the CPU offers and how fast the > > system in general is. > > Do you know why the module is not in mainline? Is there a discussion > where the kernel maintainers motivate why they don't like this solution? The module itself is 10+ years old and it is highly unlikely it will be ever merged as it uses ioctl approach - makes API compatible with OpenBSD. Meawhile AF_ALG API was introduced without anyone really interested (people are still using /dev/crypto). Also see this comparsion: http://cryptodev-linux.org/comparison.html ladis ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [RFC/PATCH 0/3] cryptodev
Hei hei, On Sun, Jul 02, 2017 at 10:30:30PM +0200, Clemens Gruber wrote: > I am wondering about the performance improvements when using the > cryptodev openssl engine. There must be some cost for the context > switches, but this is probably outweighed by the offloading. > Did you for example run openssl speed aes-128-cbc before and after? > And on what platform did you try it? fli4l [1] uses cryptodev and the experience there is, it depends on the platform. Some platforms benefit a lot, especially for OpenVPN, others not so much. Depends on what the CPU offers and how fast the system in general is. Greets Alex [1] http://www.fli4l.de/ -- »With the first link, the chain is forged. The first speech censured, the first thought forbidden, the first freedom denied, chains us all irrevocably.« (Jean-Luc Picard, quoting Judge Aaron Satie) *** GnuPG-FP: C28E E6B9 0263 95CF 8FAF 08FA 34AD CD00 7221 5CC6 *** pgpsDNc1AgBaE.pgp Description: PGP signature ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [RFC/PATCH 0/3] cryptodev
Hi, On Fri, Jun 30, 2017 at 09:25:04PM +0200, Ladislav Michl wrote: > On Fri, Jun 30, 2017 at 04:36:21PM +0200, Michael Olbrich wrote: > > Hi, > > > > On Sat, Jun 24, 2017 at 03:47:51PM +0200, Ladislav Michl wrote: > > > This serie adds support for cryptodev hardware acceleration. > > > However, there's one issue unresolved: cryptodev module > > > loading. > > > As we have three different modutils implementations available > > > and also supporting systemd and sysv init it is a bit messy > > > to generate proper config to load cryptodev at boot time. > > > So we could either leave module loading to BSP or do something > > > on ptxdist level. Thoughts? > > > > I'm not sure I like this. Keeping up to date with crypto stuff is hard > > enough as it is. I don't like adding a out-of-tree kernel module into the > > mix. > > Fair enough, but note this module is there for long time and still properly > maintained. I am wondering about the performance improvements when using the cryptodev openssl engine. There must be some cost for the context switches, but this is probably outweighed by the offloading. Did you for example run openssl speed aes-128-cbc before and after? And on what platform did you try it? Thanks, Clemens ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [RFC/PATCH 0/3] cryptodev
On Fri, Jun 30, 2017 at 04:36:21PM +0200, Michael Olbrich wrote: > Hi, > > On Sat, Jun 24, 2017 at 03:47:51PM +0200, Ladislav Michl wrote: > > This serie adds support for cryptodev hardware acceleration. > > However, there's one issue unresolved: cryptodev module > > loading. > > As we have three different modutils implementations available > > and also supporting systemd and sysv init it is a bit messy > > to generate proper config to load cryptodev at boot time. > > So we could either leave module loading to BSP or do something > > on ptxdist level. Thoughts? > > I'm not sure I like this. Keeping up to date with crypto stuff is hard > enough as it is. I don't like adding a out-of-tree kernel module into the > mix. Fair enough, but note this module is there for long time and still properly maintained. > I wouldn't mind the options for gnutls and openssl but those require > crypto/cryptodev.h, right? Where is this coming from anyways? > cryptodev.install is empty, so not from there. Unfortunately from cryptodev.targetinstall as cryprodev's Makefile reads: install: modules_install modules_install: $(MAKE) $(KERNEL_MAKE_OPTS) modules_install install -m 644 -D crypto/cryptodev.h $(DESTDIR)/$(includedir)/crypto/cryptodev.h regards, ladis ___ ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [RFC/PATCH 0/3] cryptodev
Hi, On Sat, Jun 24, 2017 at 03:47:51PM +0200, Ladislav Michl wrote: > This serie adds support for cryptodev hardware acceleration. > However, there's one issue unresolved: cryptodev module > loading. > As we have three different modutils implementations available > and also supporting systemd and sysv init it is a bit messy > to generate proper config to load cryptodev at boot time. > So we could either leave module loading to BSP or do something > on ptxdist level. Thoughts? I'm not sure I like this. Keeping up to date with crypto stuff is hard enough as it is. I don't like adding a out-of-tree kernel module into the mix. I wouldn't mind the options for gnutls and openssl but those require crypto/cryptodev.h, right? Where is this coming from anyways? cryptodev.install is empty, so not from there. Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ ptxdist mailing list ptxdist@pengutronix.de
