[nocarrier]

The two AsiaBSD papers linked from the post are good for more detail. I was a little surprised they had to hack sendfile to do the crypto in the kernel in order to get the throughput they're used to with http, but the reasons are explained in the papers.

However, I'm quite surprised Netflix went with Intel's ISA-L library for AES-GCM given Intel's perf gains were so very marginal compared to BoringSSL. I would have gone with the library that had more eyeballs on it, and in general I'd give Google the edge over writing solid, secure code than I would Intel.

[drewg123]

I'm on the team. A few limited comments:

ISA-L: There will be some more recent results presented next week at IDF: http://myeventagenda.com/sessions/0B9F4191-1C29-408A-8B61-65...

Hacking sendfile:

Note that only the bulk encryption for a limited number of ciphers is done in the kernel. All the TLS setup still happens in the userspace SSL library. So the kernel part is quite small. So it is more like hacking the bulk encryption into the kernel, not the entire library.

[mfjordvald]

Have you guys ever written anything on how you configure nginx and FreeBSD in general? Would love to read more about this.

[drewg123]

That's a great idea -- I will pass it along.

I'm afraid that most of the interesting "configuration" is to run patched kernel (async sendfile vs aio + sendfile, tls sendfile vs read/encrypt/send, etc). Of course, I work on the kernel, so I'm biased :)

[2trill2spill]

> I'm afraid that most of the interesting "configuration" is to run patched kernel (async sendfile vs aio + sendfile, tls sendfile vs read/encrypt/send, etc).

Do you have any idea if or when Netflix plans on open sourcing tls sendfile?

[drewg123]

It has always been the plan to upstream it. However, the patch is rather extensive, and it needs quite a lot of cleanup. (for example, making ISA-L pluggable)