Hi,
On 2021-07-22 00:21:16 +0200, Daniel Gustafsson wrote:
> > On 15 Jul 2021, at 04:17, Andres Freund <andres@anarazel.de> wrote:
>
> > Thomas^WA bad person recently nerdsniped me (with the help of an accidental use
> > of an SSL connection in a benchmark leading to poor results) into checking what
> > would be needed to benefit from SSL/TLS hardware acceleration (available with
> > suitable hardware, OS support (linux and freebsd) and openssl 3).
>
> Now why does that sounds so familiar.. =)
:)
> > On the client side it looks like things would be a bit harder. The main problem
> > seems to be dealing with SIGPIPE. We could possibly deal with that by moving
> > the handling of that a layer up. That's a thick nest of ugly stuff :(.
>
> My initial plan was to keep this for the backend, as the invasiveness of the
> frontend patch is unlikely to be justified by the returns of the acceleration.
There's two main reasons I'd prefer not to do that:
1) It makes it surprisingly hard to benchmark the single connection TLS
throughput, because there's no client that can pull data quick enough.
2) The main case for wanting offload imo is bulk data stuff (basebackup,
normal backup). For that you also want to be able to receive the data
fast. Outside of situations like that I don't think the gains are likely to
be meaningful given AES-NI and other similar cpu level acceleration.
> > FWIW, I don't think hardware tls acceleration is a particularly crucial thing
> > for now.
>
> Agreed, it will most likely be of limited use to most. It might however make
> sense to "get in on the ground floor" to be ready in case it's expanded on in
> kernel+OpenSSL with postgres automatically just reaping the benefits. Either
> way I was hoping to get to a patch which is close enough to what it would need
> to look like so we can decide with the facts at hand.
Yea. I also just think getting rid of the bio stuff is good for
maintainability / robustness. Relying on our own socket functions being
compatible with the openssl bio doesn't sound very future proof... Especially
not combined with our use of the data field, which of course the other bio
functions may use (as they do when ktls is enabled!).
> > I don't plan to work on this, but Thomas encouraged me to mention this on the
> > list when I mention it to him.
>
> I still have it on my TODO for after the vacation, and hope to reach that part
> of the list soon.
Cool!
Greetings,
Andres Freund
