[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <e235caf4-f51c-dccf-4eb7-548d3fa71644@de.ibm.com>
Date: Tue, 10 Jan 2017 13:27:04 +0100
From: Christian Borntraeger <borntraeger@...ibm.com>
To: Gonglei <arei.gonglei@...wei.com>, linux-kernel@...r.kernel.org,
qemu-devel@...gnu.org, virtio-dev@...ts.oasis-open.org,
virtualization@...ts.linux-foundation.org,
linux-crypto@...r.kernel.org
Cc: weidong.huang@...wei.com, claudio.fontana@...wei.com,
mst@...hat.com, luonengjun@...wei.com, hanweidong@...wei.com,
xuquan8@...wei.com, wanzongshun@...wei.com, stefanha@...hat.com,
jianjay.zhou@...wei.com, longpeng2@...wei.com,
arei.gonglei@...mail.com, davem@...emloft.net, wu.wubin@...wei.com,
herbert@...dor.apana.org.au
Subject: Re: [PATCH v8 1/1] crypto: add virtio-crypto driver
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?
Christian
Powered by blists - more mailing lists