Re: [Qemu-devel] [PATCH v8 1/2] virtio-crypto: Add virtio crypto device specification

[Ola Liljedahl]

On 05/09/2016, 09:40, "Alexander Graf" <address@hidden> wrote:

>On 09/04/2016 05:47 PM, Ola Liljedahl wrote:
>>
>> On 02/09/2016, 16:05, "Alexander Graf" <address@hidden> wrote:
>>
>>>>> There is a big problem that the control handle logic is
>>>>>synchronization,
>>>>> but the data queue
>>>>> handling logic is asynchronization. We can't combine them into one
>>>>> queue.
>>>>> It will decrease the performance because you need indentify each
>>>>>packet
>>>>> if we do this forcedly.
>>>> Are you saying that control and data operations are handled by
>>>>separate
>>>> "blocks???
>>>> If you combined control and data queues, there would have to be a (SW)
>>>> demultiplexer
>>>> that would add overhead (and potentially decrease throughout)
>>>>especially
>>>> for the data
>>>> operations?
>>> Uh, the multiplexer is as simple as a switch() statement on the opcode,
>>> no?
>> You are assuming the backend will (always) be implemented in software.
>
>If you implement it in something that is not software, multiplexing
>suddenly becomes a lot harder. What if you want to run 20 VMs on a
>single host? Would you spawn SR-IOV devices with separate control queues
>each? Or would you trap the control queue into the host and let the
>guest freely access data queues which then means one guest could
>interfere with another guest's data?
For a backend implementation in hardware, it would of course also have to
support separation and protection between clients.

I haven??t tried to understand how virtio could be made to support hardware
implementation of some interesting backends. I just want us to avoid making
interface definitions and specification that make alternative backend
implementations difficult or less efficient.

In OPNFV DPACC project, there was some prototyping of virtio-crypto with HW
offload and one conclusion was that the SW overhead was so high that you
had
to pass packets of size >1000 bytes for the HW acceleration to be worth it.
(I think the comparison was with AES).

>If you manage to give each queue its own stream ID, you could just pass
>as many real hardware queues as you like into guests, no?
>
>
>Alex
>

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.