search for: cpacf

...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 sl...

...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 sl...

...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...

...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...

..."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) > >>&g...

..."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) > >>&g...

...>>>> + .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 v...

...tatic 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...

Some hardware accelerators (like intel aseni or the s390 cpacf functions) have lower priorities than virtio crypto, and those drivers are faster than the same in the host via virtio. So let's lower the priority of virtio-crypto's algorithm, make it's higher than sofeware implimentations but lower than the hardware ones. Suggested-by: Christian Bor...

Some hardware accelerators (like intel aseni or the s390 cpacf functions) have lower priorities than virtio crypto, and those drivers are faster than the same in the host via virtio. So let's lower the priority of virtio-crypto's algorithm, make it's higher than sofeware implimentations but lower than the hardware ones. Suggested-by: Christian Bor...

Some hardware accelerators (like intel aesni or the s390 cpacf functions) have lower priorities than virtio crypto, and those drivers are faster than the same in the host via virtio. So let's lower the priority of virtio-crypto's algorithm, make it's higher than software implementations but lower than the hardware ones. Suggested-by: Christian Bor...

Some hardware accelerators (like intel aesni or the s390 cpacf functions) have lower priorities than virtio crypto, and those drivers are faster than the same in the host via virtio. So let's lower the priority of virtio-crypto's algorithm, make it's higher than software implementations but lower than the hardware ones. Suggested-by: Christian Bor...

ACK. Whoever takes this patch might want to fixup 3 typos. On 01/13/2017 07:25 AM, Gonglei wrote: > Some hardware accelerators (like intel aseni or the s390 aesni > cpacf functions) have lower priorities than virtio > crypto, and those drivers are faster than the same in > the host via virtio. So let's lower the priority of > virtio-crypto's algorithm, make it's higher than sofeware software &gt...

v8: - use per virtqueue lock instead of a whole device lock for data virtuqueue. [Halil & Xin] v7: - fix "BUG: smp_processor_id() in preemptible [00000000] code" reported by Halil, using get_cpu/put_cpu instead of calling smp_processor_id() directly. - fix a possible spinlock recursion in virtcrypto_dataq_callback(), we should release the spinlock before invoking the

v8: - use per virtqueue lock instead of a whole device lock for data virtuqueue. [Halil & Xin] v7: - fix "BUG: smp_processor_id() in preemptible [00000000] code" reported by Halil, using get_cpu/put_cpu instead of calling smp_processor_id() directly. - fix a possible spinlock recursion in virtcrypto_dataq_callback(), we should release the spinlock before invoking the