On Fri, Jan 29, 2021 at 12:34 AM Diego Santa Cruz via lists.openembedded.org <[email protected]> wrote: > > > -----Original Message----- > > From: [email protected] <openembedded- > > [email protected]> On Behalf Of Khem Raj via > > lists.openembedded.org > > Sent: 29 January 2021 02:16 > > To: Tom Hochstein <[email protected]>; openembedded- > > [email protected] > > Cc: [email protected] > > 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: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
