Re: [OE-core] [PATCH] [RFC] openssl: Enable cryptodev-linux by default
Em sex., 29 de jan. de 2021 às 18:14, Andre McCurdy escreveu: > On Fri, Jan 29, 2021 at 12:45 PM Otavio Salvador > wrote: > > > > Em sex., 29 de jan. de 2021 às 17:39, Andre McCurdy > > 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.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147466): https://lists.openembedded.org/g/openembedded-core/message/147466 Mute This Topic: https://lists.openembedded.org/mt/80195674/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] [RFC] openssl: Enable cryptodev-linux by default
On Fri, Jan 29, 2021 at 12:45 PM Otavio Salvador wrote: > > Em sex., 29 de jan. de 2021 às 17:39, Andre McCurdy > 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.brhttp://code.ossystems.com.br > Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147465): https://lists.openembedded.org/g/openembedded-core/message/147465 Mute This Topic: https://lists.openembedded.org/mt/80195674/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] [RFC] openssl: Enable cryptodev-linux by default
Em sex., 29 de jan. de 2021 às 17:39, Andre McCurdy 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.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147464): https://lists.openembedded.org/g/openembedded-core/message/147464 Mute This Topic: https://lists.openembedded.org/mt/80195674/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] [RFC] openssl: Enable cryptodev-linux by default
On Fri, Jan 29, 2021 at 12:34 AM Diego Santa Cruz via lists.openembedded.org wrote: > > > -Original Message- > > From: openembedded-core@lists.openembedded.org > c...@lists.openembedded.org> On Behalf Of Khem Raj via > > lists.openembedded.org > > Sent: 29 January 2021 02:16 > > To: Tom Hochstein ; openembedded- > > c...@lists.openembedded.org > > Cc: ota...@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). -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147463): https://lists.openembedded.org/g/openembedded-core/message/147463 Mute This Topic: https://lists.openembedded.org/mt/80195674/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] [RFC] openssl: Enable cryptodev-linux by default
> -Original Message-
> From: openembedded-core@lists.openembedded.org c...@lists.openembedded.org> On Behalf Of Khem Raj via
> lists.openembedded.org
> Sent: 29 January 2021 02:16
> To: Tom Hochstein ; openembedded-
> c...@lists.openembedded.org
> Cc: ota...@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
> > ---
> > 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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147429):
https://lists.openembedded.org/g/openembedded-core/message/147429
Mute This Topic: https://lists.openembedded.org/mt/80195674/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
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.
Signed-off-by: Tom Hochstein
---
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 = ""
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147421):
https://lists.openembedded.org/g/openembedded-core/message/147421
Mute This Topic: https://lists.openembedded.org/mt/80195674/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] [RFC] openssl: Enable cryptodev-linux by default
Em qui., 28 de jan. de 2021 às 18:36, Tom Hochstein 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 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.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147413): https://lists.openembedded.org/g/openembedded-core/message/147413 Mute This Topic: https://lists.openembedded.org/mt/80195674/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] [RFC] openssl: Enable cryptodev-linux by default
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
---
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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147412):
https://lists.openembedded.org/g/openembedded-core/message/147412
Mute This Topic: https://lists.openembedded.org/mt/80195674/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
