From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36880) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgoWE-000810-VB for qemu-devel@nongnu.org; Mon, 05 Sep 2016 03:40:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bgoW9-0002CQ-Kg for qemu-devel@nongnu.org; Mon, 05 Sep 2016 03:40:38 -0400 Received: from mx2.suse.de ([195.135.220.15]:55137) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgoW9-0002CK-6I for qemu-devel@nongnu.org; Mon, 05 Sep 2016 03:40:33 -0400 References: <1472559136-89096-1-git-send-email-arei.gonglei@huawei.com> <1472559136-89096-2-git-send-email-arei.gonglei@huawei.com> <57C82F16.6000801@suse.de> <33183CC9F5247A488A2544077AF19020B03B3096@SZXEMA503-MBS.china.huawei.com> <662664ba-c092-8f30-9994-12f5d67224f0@suse.de> <33183CC9F5247A488A2544077AF19020B03B32DB@SZXEMA503-MBS.china.huawei.com> <2289c8d7-5d4c-84e2-99df-19abd1a90c79@suse.de> From: Alexander Graf Message-ID: <57CD2170.3070006@suse.de> Date: Mon, 5 Sep 2016 09:40:32 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v8 1/2] virtio-crypto: Add virtio crypto device specification List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ola Liljedahl , "Gonglei (Arei)" , "qemu-devel@nongnu.org" , "virtio-dev@lists.oasis-open.org" Cc: "Huangpeng (Peter)" , Luonengjun , "mst@redhat.com" , "cornelia.huck@de.ibm.com" , "stefanha@redhat.com" , "denglingli@chinamobile.com" , Jani Kokkonen , "Varun.Sethi@freescale.com" , "xin.zeng@intel.com" , "brian.a.keating@intel.com" , "liang.j.ma@intel.com" , "john.griffin@intel.com" , "hanweidong@huawei.com" , "Huangweidong (C)" , "mike.caraman@nxp.com" , Claudio Fontana , "Zhoujian (jay, Euler)" On 09/04/2016 05:47 PM, Ola Liljedahl wrote: > > On 02/09/2016, 16:05, "Alexander Graf" wrote: > >>>> There is a big problem that the control handle logic is synchronizat= ion, >>>> 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 pac= ket >>>> if we do this forcedly. >>> Are you saying that control and data operations are handled by separa= te >>> "blocks=A9=F7? >>> If you combined control and data queues, there would have to be a (SW= ) >>> demultiplexer >>> that would add overhead (and potentially decrease throughout) especia= lly >>> 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? 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