The question is whether or not other full-disk encryption implementations defer to on=device encryption hardware if present. As the paper notes, with the advent of embedded AES instructions in Intel processors, there is little or no performance advantage to doing so, and given the near-certainty that a crypto implementation done by a company or group that isn't a crypto-specialist is going to be flawed, it will likely compromise security to do so.
There may not be an IO performance disadvantage to using Intel AES-NI for dmcrypt, versus in-hardware (in the drive). But there is a CPU performance impact when using it. I see ~22% x4 thread (~88% CPU out of 400%) for kcryptd processes when fully utilizing reads or writes for a single laptop hard drives at ~140MB/s with an Intel Pentium N3700 in an Intel NUC. That's obviously not a very substantial CPU. But it is nevertheless a fairly substantial CPU hit. The spare CPU cycles are available so it doesn't have an actual impact on this system.
Anyway, neither kernel fscrypt, nor dmcrypt have any dependency on drive embedded crypto. They do use AES-NI or equivalent, if available and if that support is compiled into the kernel.
