Hi, On 2021-07-15 13:59:26 -0400, Bruce Momjian wrote: > On Wed, Jul 14, 2021 at 07:17:47PM -0700, Andres Freund wrote: > > FWIW, I don't think hardware tls acceleration is a particularly crucial > > thing > > for now. Outside of backups it's rare to have the symmetric encryption part > > of > > tls be the problem these days thanks, to the AES etc functions in most of > > the > > common CPUs. > > > > I don't plan to work on this, but Thomas encouraged me to mention this on > > the > > list when I mention it to him. > > So, I am aware of CPU AES acceleration and I assume PG uses that.
Yes, it does so via openssl. But that still happens on the CPU. And what's more, there's a lot of related work in TLS that's fairly expensive (chunking up the data into TLS records etc). Some of the better NICs can do that work in the happy path, so the CPU doesn't have to do encryption nor framing. In some cases that can avoid the to-be-sent data ever being pulled into the CPU caches, but instead it can be DMA directly to the NIC. In PG's case that's particularly interesting when sending out file data in bulk, say in basebackup.c or walsender.c - the data can be sent via sendfile(), so it never goes to userspace. Here's an overview of the kernel TLS / TLS offload https://legacy.netdevconf.info/1.2/papers/ktls.pdf > It is the public key certificate verification part of TLS that we > don't use hardware acceleration for, right? That's true, but separate from what I was talking about. For most database workloads the public key stuff shouldn't be a major piece, because connection establishment shouldn't be that frequent... Greetings, Andres Freund
