Re: [Qemu-devel] [virtio-dev] RE: [PATCH v7 09/12] virtio-crypto: add data queue processing handler

[Gonglei (Arei)]

> -----Original Message-----
> From: Stefan Hajnoczi [mailto:address@hidden
> Sent: Tuesday, October 18, 2016 6:09 PM
> Subject: Re: [virtio-dev] RE: [Qemu-devel] [PATCH v7 09/12] virtio-crypto: add
> data queue processing handler
> 
> On Mon, Oct 17, 2016 at 06:29:42AM +0000, Gonglei (Arei) wrote:
> >
> > > -----Original Message-----
> > > From: Stefan Hajnoczi [mailto:address@hidden
> > > Sent: Sunday, October 16, 2016 9:23 PM
> > > Subject: Re: [Qemu-devel] [PATCH v7 09/12] virtio-crypto: add data queue
> > > processing handler
> > >
> > > On Thu, Oct 13, 2016 at 03:12:03PM +0800, Gonglei wrote:
> > > > Introduces VirtIOCryptoReq structure to store
> > > > crypto request so that we can support sync and async
> > > > crypto operation in the future.
> > >
> > > What do you mean by "sync and async" operations?
> > >
> > Synchronous and asynchronous.
> 
> I understand the words but:
> 
Sorry for my misunderstanding ;)

> 1. The virtio interface is always asynchronous because request
>    submission and completion on the virtqueue are separate steps (kick
>    and irq).  The guest always thinks the operation is asynchronous.
> 
Yes, that's right.

> 2. If you implement operations synchronously inside QEMU then monitor
>    and other QEMU threads could be blocked. Also you will not be able
>    to take advantage of parallel requests to the hardware crypto
>    accelerator!
> 
Correct. 

For different cryptodev backends, especially for hardware crypto
accelerators, usually provide asynchronous APIs for crypto operations,
such as registering callback for each crypto operations. When the crypto
operations are finished, the callback is invoked.

> So I think it makes sense to implement everything asynchronously.

Yes. I can register a bh to execute asynchronous crypto operation instead
of direct calling cryptodev crypto API in data virtqueue handling context.


Regards,
-Gonglei