Hacker News Reader

Comment by cturner | Hacker News Reader

Yesterday there was a post about a coming linux kernel feature, kernel TLS sockets. (https://news.ycombinator.com/item?id=15164568)

One of the justifications: it removes the need to copy data between kernel/user-space.

KTLS strikes me as inelegant. Socket programming requires you to reason about your frames on the wire. Proto-socket features complicate this.

A unikernel approach would allow us to eliminate unnecessary copies, and could be done with more elegance than KTLS.

View on HN

The Linux kernel is a dumping-ground, kitchen-drain of all features (20 megaLoC with no end in sight) because of their inability to isolate concerns and provide fast IPC.

You also forgot about security in this IPC which is very much not a priority for Linus. With good reasons - security community has no consensus there.

And yet able to capture the server and phone market so completely. Best isn't always best.

Shared memory and busy spinning work normally when you need that latency (high freq. trading for instance)

Is the obsession with avoiding memory copying really justified? I'd like to see some data. Is this really a bottleneck in modern systems? Is TLS a bottleneck at all for most work loads?

Memory bandwidth still matters, yes. Cache sizes are still not very big, and a copy uses more cache. Obviously you may have other bottlenecks first, but it matters once you are using 10Gb ethernet or faster, for example.

That's a good point. It's probably more a cache thing than a CPU cycles thing and that might not show up on a straightforward CPU profile.

What would happen if you used special instructions to try to implement a non-cache-polluting memcpy? Or is that even possible? It's been a while but I seem to think that modern CPUs have a variety of cache control instructions. Zero copy is great but it can be a PITA.

You have to use at least one cache line for memcpy. But you need more for pipelining the accesses probably to get good speed. Benchmarking memcpy though is complicated.

IIRC Netflix found TLS to be a bottleneck when serving 100 Gbps of static content over HTTPS, but that's an unusual case.

The kTLS paper showed pretty small speedups, so maybe the real motivation is TLS hardware offload.

Reply on news.ycombinator.com