In D41614#948592, @delphij wrote:

The change looks Okay to me but I wonder if we should separate the variable into two cached values, one for new and the other for !new.

When changing multiple providers at the same time, this would allow the library to cache both passphrases so the user don't have to enter them over and over again.

The change looks Okay to me but I wonder if we should separate the variable into two cached values, one for new and the other for !new.

Merged as https://reviews.freebsd.org/rGe4520c8bd1d3 .

Are there any objections to continuing with the creation of the vendor/openssl-3.0 branch?

In D38835#884813, @dim wrote:

In D38835#884784, @ngie wrote:

Part of what I would like to do based on informal discussions in IRC is to put OpenSSL 3 into its own subdirectory, make it into a private library (props goes to @dim for the idea!) and transition utilities in base over to OpenSSL 3, then work on the ports story with @brnrd .

If openssl3 is going to be a private lib, then ports can't use it at all, right? I see there is already security/openssl which is 1.1.1t, and security/openssl-devel which is 3.0.8 (strange, because the development version of OpenSSL is 3.1.0 but I digress). So ports would have to link against the former or the latter (and can't use both). Also, if we make a private openssl3 lib, we'll have to rename all symbols so as to not conflict with ports. Alternatively, the ports openssl versions should rename all _their_ symbols to not conflict. That might also solve the problem of mixing 1.1 and 3.0.

In any case, getting openssl3 in side-by-side is a good first step, allowing piecemeal work to be done.

In D38835#884784, @ngie wrote:

Part of what I would like to do based on informal discussions in IRC is to put OpenSSL 3 into its own subdirectory, make it into a private library (props goes to @dim for the idea!) and transition utilities in base over to OpenSSL 3, then work on the ports story with @brnrd .

Part of what I would like to do based on informal discussions in IRC is to put OpenSSL 3 into its own subdirectory, make it into a private library (props goes to @dim for the idea!) and transition utilities in base over to OpenSSL 3, then work on the ports story with @brnrd .

In D38835#884625, @jkim wrote:

In D38835#884575, @ngie wrote:

I followed a different import process than what’s described in FreeBSD-UPGRADE because it was much simpler for me to use rsync -av —-delete to update the contents than multiple calls to find/tar/comm.

Actually, we need to rewrite both FreeBSD-upgrade and FreeBSD-Xlist from scratch for OpenSSL 3.0 because it is quite different.

In D38835#884575, @ngie wrote:

I followed a different import process than what’s described in FreeBSD-UPGRADE because it was much simpler for me to use rsync -av —-delete to update the contents than multiple calls to find/tar/comm.

In D38835#884175, @emaste wrote:

I assume your vendor/openssl-3.0 branch started from the current vendor/openssl?

I assume your vendor/openssl-3.0 branch started from the current vendor/openssl?

https://reviews.freebsd.org/D16215 (+ https://reviews.freebsd.org/D16216 for IPsec and https://reviews.freebsd.org/D16219 for aesni(4) ) solves the problem generally.

I agree w/ cem that we need a general solution to this. I'm fine w/ this patch, but I do question the wisdom in making this code aesni only. This code really needs to be turned into a library which any OCF driver can use, as this performance problem is not limited to aesni.

In D15389#328653, @emeric.poupon_stormshield.eu wrote:

So what is the plan here? Wait for somebody willing to do the session management in OCF right?

In D15389#328341, @cem wrote:

In D15389#328317, @emeric.poupon_stormshield.eu wrote:

Nobody wants this? It is definitely better than the current code though.

Sure, it improves performance (I haven't tested, but I'm quite willing to take your word for it) of a single OCF driver in the case that some consumer is allocating a lot of sessions (or maybe a reasonable number of sessions on a high core-count CPU). But that doesn't make it definitely better.

It adds complexity and perpetuates the problem that every OCF driver needs to copy and paste crappy session management. I think a general solution that moves the session management into OCF and out of drivers is a better way to fix this. You don't need the RB tree if sessions are just pointers.

In D15389#328317, @emeric.poupon_stormshield.eu wrote:

Nobody wants this? It is definitely better than the current code though.

Nobody wants this? It is definitely better than the current code though.

Remove bad comment

Remarks

In D15389#324522, @cem wrote:

I agree that the current system sucks and that it does not scale with multiple sessions. I'm not sure a binary tree is the right replacement, though. And probably session management should be lifted out into OCF (OpenCrypto Framework) so that all drivers can benefit from it without copy-pasting.

OCF has a number of shortcomings which John detailed here: https://lists.freebsd.org/pipermail/freebsd-arch/2018-January/018835.html

I agree that the current system sucks and that it does not scale with multiple sessions. I'm not sure a binary tree is the right replacement, though. And probably session management should be lifted out into OCF (OpenCrypto Framework) so that all drivers can benefit from it without copy-pasting.