On Tue, 12 Jan 2016, Mark Brown wrote: > On Tue, Jan 12, 2016 at 06:31:19PM -0500, Mikulas Patocka wrote: > > On Mon, 4 Jan 2016, Mark Brown wrote: > > > > The main thing the out of tree req-dm-crypt code is doing was using a > > > larger block size which does seem like a reasonable thing to allow > > > people to tune for performance tradeofffs but I undertand that's a lot > > > harder to achieve in a good way than one might hope. > > > But as Milan pointed out, that larger block size doesn't work if you > > process requests with different sizes - the data encrypted with one > > request size won't match if you decrypt them with a different request > > size. > > Sure, you need to fix that block size. > > > Does the hardware encryption you are optimizing for allow setting > > arbitrary tweaks in XTS mode? What is the specific driver you are > > optimizing for? > > This isn't targeted at a specific driver or system, it's trying to make > dm-crypt better able to make use of hardware acceleration in general. If the hardware acceleration doesn't allow to set arbitrary XTS tweak, then this "large block" optimization on XTS can't be done at all. So, we need to know which driver(s) you want to optimize for and how do those driver(s) handle tweak generation. Mikulas -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
