Cloudflare Improving Linux Disk Encryption Performance - Doubling The Throughput

[Veerappan]

The thing I was hoping to see in the cloudflare blog post, but it seems they skipped, was what would be the effect of reducing, but not necessarily eliminating the number of async queuing layers. The dm-crypt queuing code was written when the Crypto API was still synchronous. The Crypto API has been updated to be asynchronous by adding its own internal queuing.

What amount of benefit would be realized by just removing the queuing in the dm-crypt code, instead of removing it in both layers?

[torsionbar28]

Maybe this is a silly question... Why disk encryption on a server? I thought this was a protection for "data at rest", e.g. a powered off laptop, unmounted disk, etc

Because the moment someone malicious takes a drive out of the server, or takes the whole server itself, any data it contains becomes "data at rest". Server disk encryption protects this data against the theft of a drive or server. It also protects the data in the event the hardware gets lost during a move. It also protects the data after the server has been decommissioned and disposed of. For all of these reasons, it has become mandated by law in certain industries.

[willmore]

The thing I was hoping to see in the cloudflare blog post, but it seems they skipped, was what would be the effect of reducing, but not necessarily eliminating the number of async queuing layers. The dm-crypt queuing code was written when the Crypto API was still synchronous. The Crypto API has been updated to be asynchronous by adding its own internal queuing.

What amount of benefit would be realized by just removing the queuing in the dm-crypt code, instead of removing it in both layers?

If you read through, there's a point in the process where that's what they did. There was a small improvement, but nothing like what you would expect if it were limited by crypto overhead.

[Veerappan]

If you read through, there's a point in the process where that's what they did. There was a small improvement, but nothing like what you would expect if it were limited by crypto overhead.

Huh, thought I had gone through the whole thing. Must've unconsciously skimmed a bit.

Edit: I think we just read it differently. From what I got out of it, they modified both the dm-crypt AND Crypto API code to remove queuing and make everything synchronous, although they left a threading/queuing toggle in their dm-crypt modifications. But it seems like in the vast majority of the time, their modified code uses synchronous cipher implementations whenever possible.

I was wondering about the opposite case. Leave Crypto API async, but remove the queuing from dm-crypt. I didn't see any numbers where they left Crypto API async, but modified dm-crypt to remove its queuing..

[archsway]

"Doubling The Throughput" sounds fishy to say the least, coz that's only possible if FDE at least halves throughput, which I seriously doubt.

Depends on what type of drive you are using:

For the purpose of this post we will use the fastest disks available out there - that is no disks.

[anarki2]

Depends on what type of drive you are using:

In which case it's exactly what I thought it was: they didn't double throughput but halve overhead instead, completely different things. In any case, it must be single-digit percentage increase in real-world actual throughput, since the performance hit is already so small.

[caligula]

In which case it's exactly what I thought it was: they didn't double throughput but halve overhead instead, completely different things. In any case, it must be single-digit percentage increase in real-world actual throughput, since the performance hit is already so small.

So, are you saying they should not have done it?

[anarki2]

So, are you saying they should not have done it?

? I said nothing close to that. I said this is a clickbait article, not more, not less.

[Termy]

That sounds nice, hopefully it will be mainlined soon™
My 3800x caps out at around 2.1gb/s. So PCIe4 would be kind of pointless ^^

[Buntolo]

Anyone got a way to email the author? I'm curious how their changes effect ARM. I don't believe they have the same FPU context issues for their crypto instructions. Then again the ARM crypto modules may be labled differently.

Couldn't find an email, your best bet is asking on the Disqus comment section on the Cloudflare blog:

https://blog.cloudflare.com/speeding-up-linux-disk-encryption/

or on his twitter:

https://twitter.com/ignatkn