On 01/10/2017 01:56 PM, Christian Borntraeger wrote: > On 01/10/2017 01:36 PM, Gonglei (Arei) wrote: >> Hi, >> >>> >>> On 12/15/2016 03:03 AM, Gonglei wrote: >>> [...] >>>> + >>>> +static struct crypto_alg virtio_crypto_algs[] = { { >>>> + .cra_name = "cbc(aes)", >>>> + .cra_driver_name = "virtio_crypto_aes_cbc", >>>> + .cra_priority = 501, >>> >>> >>> This is still higher than the hardware-accelerators (like intel aesni or the >>> s390 cpacf functions or the arm hw). aesni and s390/cpacf are supported by the >>> hardware virtualization and available to the guests. I do not see a way how >>> virtio >>> crypto can be faster than that (in the end it might be cpacf/aesni + overhead) >>> instead it will very likely be slower. >>> So we should use a number that is higher than software implementations but >>> lower than the hw ones. >>> >>> Just grepping around, the software ones seem be be around 100 and the >>> hardware >>> ones around 200-400. So why was 150 not enough? >>> >> I didn't find a documentation about how we use the priority, and I assumed >> people use virtio-crypto will configure hardware accelerators in the >> host. So I choosed the number which bigger than aesni's priority. > > Yes, but the aesni driver will only bind if there is HW support in the guest. > And if aesni is available in the guest (or the s390 aes function from cpacf) > it will always be faster than the same in the host via virtio.So your priority > should be smaller. any opinion on this? -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html