Hi, On 2021-07-22 00:21:16 +0200, Daniel Gustafsson wrote: > > On 15 Jul 2021, at 04:17, Andres Freund <and...@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
