On Thu, Jan 12, 2017 at 02:36:54PM +0100, Lukas Czerner wrote: > > There is hardware to accleerate compression as well. I do not expect it > to require more than ICE (likely much less considering key management > encryption requires), but we should keep in mind that any support or > potential api we'll have might get used by compression as well. So I'd > like to be part of this discussion on LSF. The thing that makes compression tricky is that the size of the input data and output data is different. And with in-line crypto, the premise that you send plaintext to the device driver, which sends it to the hardware controller, and it gets encrypted before it's passed to the storage device. I'm not aware of any compression engines that work in a similar way. If someone were to do that, presumably it would have return information back to the file system about how many sectors were actually written to. Most of the hardware compression engines work today much like hardware accelerated crypto, and could use the existing asynchronous crypto interface. If the file system wants to know how much space the compressed space used, so it can decide where on the storage device to place the data. So it becomes tricky to do that in the context of an off-load compression engine, unless it has on-board buffering so that it becomes a two-phase process. First you send it to the compression engine, it tells you how much it was able to compress it, and then you send a command asking it to send it on to the storage device by handing it a vector of start sector and lengths. So it might not have a lot of commonality with ICE as we currently see as shipping hardware. Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
