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