DepOpenSSL, initialize

[jmillan]

It's difficult to know if we are using HW acceleration for encrypting SRTP.

In theory we are. We are compiling libsrtp with openssl so the first makes use of HW capabilities of the second. I've realised that it is by calling OPENSSL_init_ssl() that the corresponding capability bits are filled, which are used for hardware encryption.

I've added two logs, before and after openssl initialization which show the CPU info. In my case arm64 I have the same values:

DepOpenSSL::operator()() | openssl CPU info before init: "CPUINFO: OPENSSL_armcap=0x7d" +0ms
DepOpenSSL::operator()() | openssl CPU info after init : "CPUINFO: OPENSSL_armcap=0x7d" +1ms

Which shows like the CPU capability bits are already filled even before calling OPENSSL_init_ssl(). So perhaps calling this method is not needed.

@vpalmisano, I know you played with openssl in the past. Do you have any opinion about this? Anyone?

I'd like to know if we are using HW capabilities in libsrtp.

NOTE: I've made a local performance tests. Using HW capabilities makes a great difference:

With HW capabilities:

 _OPENSSL_armcap="~0x200000200000000" openssl speed -elapsed -evp aes-128-cbc
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
AES-128-CBC     498907.71k  1280811.39k  1356705.88k  1450232.35k  1462927.36k  1400826.54k

Without HW capabilities:

OPENSSL_armcap="~0x200000200000000" openssl speed -elapsed -evp aes-128-cbc
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
AES-128-CBC     287775.07k   292925.91k   272145.52k   286081.37k   300997.49k   296943.62k

EDIT:

In order to know if libsrtp is making use of HW encryption start the media server with the corresponding ENV variable and without it, and start a router with many video consumers. Ie:

This will disable the capabilities for arm64, change the name to OPENSSL_ia32cap for an intel CPU.

OPENSSL_armcap="~0x200000200000000" npm run start

In my case, disabling the HW capabilities takes twice as much CPU on a arm64 (Mac M1)

[ibc]

Do we need these before/after logs permanently? I assume we don't once we know how it works.

[vpalmisano]

I see this on my machine (Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz) and OPENSSL_ia32cap value is the same emitted by the openssl command:

  mediasoup:Channel [pid:458297] DepLibUV::PrintVersion() | libuv version: "1.44.2" +0ms
  mediasoup:Channel [pid:458297] DepOpenSSL::operator()() | openssl version: "OpenSSL 3.0.8 7 Feb 2023" +0ms
  mediasoup:Channel [pid:458297] DepOpenSSL::operator()() | openssl CPU info before init: "CPUINFO: OPENSSL_ia32cap=0x7ffaf3bfffebffff:0x40000018029c67af" +0ms
  mediasoup:Channel [pid:458297] DepOpenSSL::operator()() | openssl CPU info after init : "CPUINFO: OPENSSL_ia32cap=0x7ffaf3bfffebffff:0x40000018029c67af" +0ms

[jmillan]

So it seems the caps are loaded without the need to call OPENSSL_init_ssl().

Still we are not 100% sure HW encryption is being used.

I'm keeping this PR open for a while just for discussion.

[jmillan]

Please, see the Edit section of the issue description. We have an easy way to know if HW encryption is being used.

I've kept just a single log line in this PR showing the CPU info, which I'll commit. I've removed the OpenSSL initialization as it seems it's not needed.