Hi Ondrej, On 12 January 2017 at 18:29, Ondrej Mosnacek <omosna...@gmail.com> wrote: > This patch converts dm-crypt to use bulk requests when invoking skcipher > operations, allowing the crypto drivers to process multiple sectors at once, > while reducing the overhead caused by the small sector size. > > The new code detects if multiple sectors from a bio are contigously stored > within a single page (which should almost always be the case), and in such > case > processes all these sectors via a single bulk request. > > Note that the bio can also consist of several (likely consecutive) pages, > which > could be all bundled in a single request. However, since we need to specify an > upper bound on how many sectors we are going to send at once (and this bound > may affect the amount of memory allocated per single request), it is best to > just limit the request bundling to a single page.
The initial goal of our proposal was to process the encryption requests with the maximum possible block sizes with a hardware which has automated iv generation capabilities. But when it is done in software, and if the bulk requests are processed sequentially, one block at a time, the memory foot print could be reduced even if the bulk request exceeds a page. While your patch looks good, there are couple of drawbacks one of which is the maximum size of a bulk request is a page. This could limit the capability of the crypto hardware. If the whole bio is processed at once, which is what qualcomm's version of dm-req-crypt does, it achieves an even better performance. > Note that if the 'keycount' parameter of the cipher specification is set to a > value other than 1, dm-crypt still sends only one sector in each request, > since > in such case the neighboring sectors are encrypted with different keys. This could be avoided if the key management is done at the crypto layer. Thanks, Binoy -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
