On Wed, 24 May 2017 04:13:47 +0300 "Michael S. Tsirkin" <m...@redhat.com> wrote:
> On Tue, May 23, 2017 at 04:08:25PM +0000, Zeng, Xin wrote: > > Hi, Michael, > > As you know, Lei Gong from Huawei and I are co-working on virtio crypto > > device spec, he is focusing on symmetric algorithm part, I am focusing on > > asymmetric part. Now I am planning the implementation for asymmetric part, > > would you please give me your point regarding the questions below? > > Current virtio crypto device implementation from Lei Gong: > > The virtio crypto device implementation has been upstreamed to QEMU and > > it has a qemu backend implementation for symmetric algorithm part, the > > front end Linux device driver for symmetric part has been upstreamed to > > Linux kernel as well. > > My questions: > > From my side, I planned to add the asymmetric part support in upstreamed > > front end device driver, and I don't want to add the asymmetric algorithm > > support to current virtio crypto device's qemu backend, instead, I would > > like to implement and upstream a DPDK vhost-user based backend for > > asymmetric algorithm, and accordingly Lei Gong will help to upstream a > > vhost user agent for virtio crypto device in QEMU, is this approach > > acceptable? Is a qemu backend a mandatory requirement for the virtio crypto > > device? Is there a general policy for this? > > > > Thanks > > Parity on QEMU side is naturally preferable. I don't think we should require > it > at all times, but if there's no implementation outside vhost-user, > and if the feature includes a non-trivial amount of code, how > will it be tested? I don't think we want to require all testers to use > dpdk. An implementation under tests using libvhost-user might > be a solution. From the s390 perspective, I'd naturally prefer a qemu implementation. I think there is value in being able to try it out on a variety of platforms, so that you can shake out problems such as endianness easily.