Playing with Kernel TLS in Linux 4.13 and Go

On a first look at the first function (tls_sw_sendmsg), we appear to have:

- send_end is the normal cleanup target at the end of the function, that's common and found almost everywhere;

- alloc_encrypted, alloc_plaintext, push_record seem to be "retry" labels, where the code goes back and tries again;

- fallback_to_reg_send is the "then" case of an if, could be removed by inverting the sense of the test;

- wait_for_sndbuf, wait_for_memory are in the style of a cleanup target, but they end by jumping to one of the "retry" labels above;

- trim_sgl is... well, it seems an attempt to avoid code duplication, or something like that, the "goto trim_sgl;" could be replaced by "trim_both_sgl(sk, orig_size); goto send_end;"

Yeah, this code looks more like assembly than C. That appears to be the kind of hand-optimized code usually reserved for hot functions, where the "normal" case encounters as few branches as possible; the fallback_to_reg_send case points to that (the normal case would be the one without the goto). So the way to understand the control flow of these functions would be: ignore the gotos on first reading, since that would be the normal case, and after that look at each goto and understand what it does.

How did you deal with certificate validation?

He mentions that fb noticed significant performance improvement [1].

You should see improvements in some cases, ie. when you can do zero-copy transfers (avoiding kernel->user and then user->kernel data copying), in other words when you pipe data from one socket/file to the other socket/file.

[1] https://netdevconf.org/1.2/papers/ktls.pdf