[PATCH] [RFC] openssl: Enable cryptodev-linux by default

[PATCH] [RFC] openssl: Enable cryptodev-linux by default

[Tom Hochstein]

This is a Request for Comment. Would it be a good idea to enable cryptodev-linux
by default, gaining hardware acceleration where supported? Are there any
unacceptable drawbacks? What happens on hardware without acceleration?

Signed-off-by: Tom Hochstein <tom.hochstein@nxp.com>
---
 meta/recipes-connectivity/openssl/openssl_1.1.1i.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb b/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
index 5617f337e0..d4c19f1a52 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
@@ -28,7 +28,7 @@ SRC_URI[sha256sum] = "e8be6a35fe41d10603c3cc635e93289ed00bf34b79671a3a4de64fcee0
 inherit lib_package multilib_header multilib_script ptest
 MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"
 
-PACKAGECONFIG ?= ""
+PACKAGECONFIG ?= "cryptodev-linux"
 PACKAGECONFIG_class-native = ""
 PACKAGECONFIG_class-nativesdk = ""
 
-- 
2.17.1

Re: [OE-core] [PATCH] [RFC] openssl: Enable cryptodev-linux by default

[Otavio Salvador]

Em qui., 28 de jan. de 2021 às 18:36, Tom Hochstein
<tom.hochstein@nxp.com> escreveu:
>
> This is a Request for Comment. Would it be a good idea to enable cryptodev-linux
> by default, gaining hardware acceleration where supported? Are there any
> unacceptable drawbacks? What happens on hardware without acceleration?
>
> Signed-off-by: Tom Hochstein <tom.hochstein@nxp.com>

Tom and I were discussing about this and I suggested him to raise the
issue here. We are not aware of drawbacks  but as we are not experts
on this field we'd like to receive feedback from the community prior
sending the formal patch for it.


-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854          Mobile: +1 (347) 903-9750

Re: [OE-core] [PATCH] [RFC] openssl: Enable cryptodev-linux by default

[Khem Raj]

On 1/28/21 1:35 PM, Tom Hochstein wrote:
> This is a Request for Comment. Would it be a good idea to enable cryptodev-linux
> by default, gaining hardware acceleration where supported? Are there any
> unacceptable drawbacks? What happens on hardware without acceleration?
> 

this perhaps helps with devices that include a hardware crypto device 
but not as much with one;s thats fine but we use qemu machines quite a 
bit in testing so it would be good to get a readout on qemu secondly, if 
it does not, then maybe we should see if defining it via 
MACHINE_FEATUREs might be an option to enable it.

> Signed-off-by: Tom Hochstein <tom.hochstein@nxp.com>
> ---
>   meta/recipes-connectivity/openssl/openssl_1.1.1i.bb | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb b/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
> index 5617f337e0..d4c19f1a52 100644
> --- a/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
> +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
> @@ -28,7 +28,7 @@ SRC_URI[sha256sum] = "e8be6a35fe41d10603c3cc635e93289ed00bf34b79671a3a4de64fcee0
>   inherit lib_package multilib_header multilib_script ptest
>   MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"
>   
> -PACKAGECONFIG ?= ""
> +PACKAGECONFIG ?= "cryptodev-linux"
>   PACKAGECONFIG_class-native = ""
>   PACKAGECONFIG_class-nativesdk = ""
>   
> 
> 
> 
> 
> 

Re: [OE-core] [PATCH] [RFC] openssl: Enable cryptodev-linux by default

[Diego Santa Cruz]

> -----Original Message-----
> From: openembedded-core@lists.openembedded.org <openembedded-
> core@lists.openembedded.org> On Behalf Of Khem Raj via
> lists.openembedded.org
> Sent: 29 January 2021 02:16
> To: Tom Hochstein <tom.hochstein@nxp.com>; openembedded-
> core@lists.openembedded.org
> Cc: otavio@ossystems.com.br
> Subject: Re: [OE-core] [PATCH] [RFC] openssl: Enable cryptodev-linux by
> default
> 
> 
> 
> On 1/28/21 1:35 PM, Tom Hochstein wrote:
> > This is a Request for Comment. Would it be a good idea to enable
> cryptodev-linux
> > by default, gaining hardware acceleration where supported? Are there any
> > unacceptable drawbacks? What happens on hardware without
> acceleration?
> >
> 
> this perhaps helps with devices that include a hardware crypto device
> but not as much with one;s thats fine but we use qemu machines quite a
> bit in testing so it would be good to get a readout on qemu secondly, if
> it does not, then maybe we should see if defining it via
> MACHINE_FEATUREs might be an option to enable it.
> 

I think that making it a MACHINE_FEATURES would effectively make the task signatures for openssl be machine dependent and that would also make all recipes which depend directly or indirectly on openssl (and there are a lot!) have their task signatures be machine dependent, so they would need to have their PACKAGE_ARCH set to MACHINE_ARCH to avoid triggering spurious rebuilds when switching between machines with and without cryptodev-linux in MACHINE_FEATURES.

So MACHINE_FEATURES does not look like a viable option, a DISTRO_FEATURES might be, although it does not really look like a nice fit either.

> > Signed-off-by: Tom Hochstein <tom.hochstein@nxp.com>
> > ---
> >   meta/recipes-connectivity/openssl/openssl_1.1.1i.bb | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
> b/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
> > index 5617f337e0..d4c19f1a52 100644
> > --- a/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
> > +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
> > @@ -28,7 +28,7 @@ SRC_URI[sha256sum] =
> "e8be6a35fe41d10603c3cc635e93289ed00bf34b79671a3a4de64fcee0
> >   inherit lib_package multilib_header multilib_script ptest
> >   MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"
> >
> > -PACKAGECONFIG ?= ""
> > +PACKAGECONFIG ?= "cryptodev-linux"
> >   PACKAGECONFIG_class-native = ""
> >   PACKAGECONFIG_class-nativesdk = ""
> >
> >
> >
> >
> >
> >

-- 
Diego Santa Cruz, PhD
Technology Architect
spinetix.com

 

Re: [OE-core] [PATCH] [RFC] openssl: Enable cryptodev-linux by default

[Andre McCurdy]

On Fri, Jan 29, 2021 at 12:34 AM Diego Santa Cruz via
lists.openembedded.org
<diego.santacruz=spinetix.com@lists.openembedded.org> wrote:
>
> > -----Original Message-----
> > From: openembedded-core@lists.openembedded.org <openembedded-
> > core@lists.openembedded.org> On Behalf Of Khem Raj via
> > lists.openembedded.org
> > Sent: 29 January 2021 02:16
> > To: Tom Hochstein <tom.hochstein@nxp.com>; openembedded-
> > core@lists.openembedded.org
> > Cc: otavio@ossystems.com.br
> > Subject: Re: [OE-core] [PATCH] [RFC] openssl: Enable cryptodev-linux by
> > default
> >
> >
> >
> > On 1/28/21 1:35 PM, Tom Hochstein wrote:
> > > This is a Request for Comment. Would it be a good idea to enable
> > cryptodev-linux
> > > by default, gaining hardware acceleration where supported? Are there any
> > > unacceptable drawbacks? What happens on hardware without
> > acceleration?
> > >
> >
> > this perhaps helps with devices that include a hardware crypto device
> > but not as much with one;s thats fine but we use qemu machines quite a
> > bit in testing so it would be good to get a readout on qemu secondly, if
> > it does not, then maybe we should see if defining it via
> > MACHINE_FEATUREs might be an option to enable it.
>
> I think that making it a MACHINE_FEATURES would effectively make the task signatures for openssl be machine dependent and that would also make all recipes which depend directly or indirectly on openssl (and there are a lot!) have their task signatures be machine dependent, so they would need to have their PACKAGE_ARCH set to MACHINE_ARCH to avoid triggering spurious rebuilds when switching between machines with and without cryptodev-linux in MACHINE_FEATURES.
>
> So MACHINE_FEATURES does not look like a viable option, a DISTRO_FEATURES might be, although it does not really look like a nice fit either.

MACHINE and DISTRO features are global variables which should be
reserved for configuration decisions which affect multiple recipes (so
that multiple recipes can be configured together under the control of
one option). It doesn't make much sense to create a new MACHINE or
DISTRO feature if it's only going to be used by one recipe.

If a distro or BSP layer wants to enable cryptodev-linux support in
openssl they can already do so by creating a .bbappend for openssl
which adds the PACKAGECONFIG. ie if we decide that the option should
be left disabled by default but controllable by the distro or BSP
layer then no further changes are required - we already have a fully
functional mechanism to do that.

Going back to the original question of whether cryptodev-linux should
be enabled by default, I would say no. It's very much the legacy
approach and in the absence of benchmarks to prove otherwise I doubt
it gives any advantage in performance on modern platforms (especially
CPUs with dedicated crypto instructions).

Re: [OE-core] [PATCH] [RFC] openssl: Enable cryptodev-linux by default

[Otavio Salvador]

Em sex., 29 de jan. de 2021 às 17:39, Andre McCurdy
<armccurdy@gmail.com> escreveu:
>
> If a distro or BSP layer wants to enable cryptodev-linux support in
> openssl they can already do so by creating a .bbappend for openssl
> which adds the PACKAGECONFIG. ie if we decide that the option should
> be left disabled by default but controllable by the distro or BSP
> layer then no further changes are required - we already have a fully
> functional mechanism to do that.


DISTRO yes, BSP is harder. If we enable it, it becomes MACHNE_ARCH as
well as all packages which depends on it.

> Going back to the original question of whether cryptodev-linux should
> be enabled by default, I would say no. It's very much the legacy
> approach and in the absence of benchmarks to prove otherwise I doubt
> it gives any advantage in performance on modern platforms (especially
> CPUs with dedicated crypto instructions).


Tom, this is indeed the most important aspect to discuss. We need to
check if latest openssl with new Linux kernels still require
cryptodev-linux to use the acceleration.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854          Mobile: +1 (347) 903-9750

Re: [OE-core] [PATCH] [RFC] openssl: Enable cryptodev-linux by default

[Andre McCurdy]

On Fri, Jan 29, 2021 at 12:45 PM Otavio Salvador
<otavio.salvador@ossystems.com.br> wrote:
>
> Em sex., 29 de jan. de 2021 às 17:39, Andre McCurdy
> <armccurdy@gmail.com> escreveu:
> >
> > If a distro or BSP layer wants to enable cryptodev-linux support in
> > openssl they can already do so by creating a .bbappend for openssl
> > which adds the PACKAGECONFIG. ie if we decide that the option should
> > be left disabled by default but controllable by the distro or BSP
> > layer then no further changes are required - we already have a fully
> > functional mechanism to do that.
>
> DISTRO yes, BSP is harder. If we enable it, it becomes MACHNE_ARCH as
> well as all packages which depends on it.

That's a concern if you're trying to create a package feed. But in
that case you should already be taking care that BSP layers don't
change the way recipes in common layers are built. ie this is
something you would be controlling from a distro layer anyway.

If you don't care about maintaining a package feed (which I guess is
the majority of us?) then BSP layers which contain .bbappend files for
recipes in common layers works just fine.

> > Going back to the original question of whether cryptodev-linux should
> > be enabled by default, I would say no. It's very much the legacy
> > approach and in the absence of benchmarks to prove otherwise I doubt
> > it gives any advantage in performance on modern platforms (especially
> > CPUs with dedicated crypto instructions).
>
>
> Tom, this is indeed the most important aspect to discuss. We need to
> check if latest openssl with new Linux kernels still require
> cryptodev-linux to use the acceleration.
>
> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9 9981-7854          Mobile: +1 (347) 903-9750

Re: [OE-core] [PATCH] [RFC] openssl: Enable cryptodev-linux by default

[Otavio Salvador]

Em sex., 29 de jan. de 2021 às 18:14, Andre McCurdy
<armccurdy@gmail.com> escreveu:
> On Fri, Jan 29, 2021 at 12:45 PM Otavio Salvador
> <otavio.salvador@ossystems.com.br> wrote:
> >
> > Em sex., 29 de jan. de 2021 às 17:39, Andre McCurdy
> > <armccurdy@gmail.com> escreveu:
> > >
> > > If a distro or BSP layer wants to enable cryptodev-linux support in
> > > openssl they can already do so by creating a .bbappend for openssl
> > > which adds the PACKAGECONFIG. ie if we decide that the option should
> > > be left disabled by default but controllable by the distro or BSP
> > > layer then no further changes are required - we already have a fully
> > > functional mechanism to do that.
> >
> > DISTRO yes, BSP is harder. If we enable it, it becomes MACHNE_ARCH as
> > well as all packages which depends on it.
>
> That's a concern if you're trying to create a package feed. But in
> that case you should already be taking care that BSP layers don't
> change the way recipes in common layers are built. ie this is
> something you would be controlling from a distro layer anyway.
>
> If you don't care about maintaining a package feed (which I guess is
> the majority of us?) then BSP layers which contain .bbappend files for
> recipes in common layers works just fine.

Also build time is a lot bigger.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854          Mobile: +1 (347) 903-9750