AES-NI XTS To See 2~3x Performance Recovery After Regressing Hard From Retpolines

[phoronix]

Phoronix: AES-NI XTS To See 2~3x Performance Recovery After Regressing Hard From Retpolines

It turns out the Intel/AMD AES-NI implementation of XTS regressed hard from the Retpolines functionality merged nearly three years ago for mitigating Spectre... But now the crypto performance with the AES-NI XTS implementation is set to recover from that regression with a huge improvement thanks to a new set of patches...

http://www.phoronix.com/scan.php?page=news_item&px=AES-NI-XTS-Retpolines-Regress

[obri]

"AES-NI XTS"

I first thought it is an article about Elons child

[caligula]

So, apparently this can be compared using 'cryptsetup benchmark' ?

[ebiggers]

So, apparently this can be compared using 'cryptsetup benchmark' ?

Kind of. cryptsetup benchmark uses the userspace interface to the kernel crypto API (AF_ALG). So it has a lot of overhead, and it isn't good for benchmarking algorithms that are very fast, such as AES-NI accelerated algorithms. It will show some improvement, but probably not the 2x that was seen in an in-kernel benchmark.

[archkde]

Ah, so that's why my disk access got so slow. Nice improvement.

[djf_]

That's cool.

From what I understand, there is more that can be done to improve performance a lot for certain loads, admittedly not loads typically relevant to most applications.

I've read that dmcrypt/kcrytpd (as opposed to cryptsetup) is async with using queues etc, and affects latency. Which I think isn't normally a problem, but shows up in fio based direct random 4k read/write tests compared to no crypt when using a non bandwidth limited block device (demonstrated on a ramdisk, but maybe relevant for some crazy nvme setups?).

For the likes of CloudFlare apparently this is relevant, they suggest the the patches from the following email chain makes using dmcrypt in their caching remove patchy response times:

https://lore.kernel.org/lkml/[email protected]/

[Alex/AT]

... and no one knows where this obtrusive and overbloated mitigation crap shoots next ...
(that's to strenghten the point h/w issues of such a scale should be fixed in h/w and not mitigated in software)

[polarathene]

So performance is 2-3x better than the regressed performance? How does that compare to without the mitigation regressed performance? Is it back to parity, close to, or still quite a bit slower?...or faster than it used to be without mitigations as well?