Re: [Qemu-devel] [PATCH v14 0/2] virtio-crypto: virtio crypto device specification

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Jan 04, 2017 at 01:03:21AM +0000, Gonglei (Arei) wrote:
> Hi Stefan,
> 
> >
> > Subject: Re: [Qemu-devel] [PATCH v14 0/2] virtio-crypto: virtio crypto device
> > specification
> > 
> > On Mon, Dec 26, 2016 at 02:38:29AM +0000, Gonglei (Arei) wrote:
> > > Both Alex and Stefan mentioned that the process of create/close a session
> > > makes we have a least one full round-trip cost from guest to host to guest
> > > to be able to send any data for symmetric algorithms. It gets ourself into
> > > synchronization troubles in some scenarios like a web server handling lots
> > > of small requests whose algorithms and keys are different.
> > >
> > > Because the virtio crypto specification has not been voted yet and v15 is on
> > the way.
> > > I'd like to make some changes in order to support those scenarios better.
> > That means
> > > we will support one-blob request (no sessions) as well for symmetric
> > > algorithms, including HASH, MAC services. The benefit is obvious for
> > > HASH service because it's usually a one-blob operation.
> > >
> > > The main changes will be:
> > >  1) using the flag property of struct virtio_crypto_op_header to identify the
> > >     type of crypto request. Aka Is it a session-based or non-session
> > request?
> > >     The flag is not used currently, so we can make use of it.
> > >
> > >  2) extending virtio_crypto_*_para structures, for example, add the content
> > of
> > >     struct virtio_crypto_cipher_session_para into struct
> > virtio_crypto_cipher_para.
> > >     It's true that will increase the size of each crypto request after this
> > change.
> > >
> > > Does it make sense? Thanks!
> > 
> > That sounds good.  Hopefully many crypto API users only use a single
> > operation and can therefore benefit from this optimization.
> > 
> Thanks for your feedback. I'll start this work.
> 
> Regards,
> -Gonglei

I worry what's going to happen with the virtio driver
I merged upstream though. Do you plan to make changes
compatible with it?


-- 
MST