From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40714) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBGAR-0001lP-5B for qemu-devel@nongnu.org; Mon, 28 Nov 2016 02:16:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBGAO-000453-0x for qemu-devel@nongnu.org; Mon, 28 Nov 2016 02:15:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47368) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cBGAN-00044o-Qv for qemu-devel@nongnu.org; Mon, 28 Nov 2016 02:15:55 -0500 Date: Mon, 28 Nov 2016 15:15:52 +0800 From: Fam Zheng Message-ID: <20161128071552.GB23163@lemon.cpc> References: <20161118133611.GC5371@redhat.com> <40265568-6388-e302-0bbf-a08a6746a686@redhat.com> <5DCF5E88-0BC6-443B-B557-9A72D32A4D49@veritas.com> <20161124111135.GC9117@stefanha-x1.localdomain> <20161124160856.GB13535@stefanha-x1.localdomain> <3B08C602-0033-4FCD-AE83-F0962322A7F7@veritas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B08C602-0033-4FCD-AE83-F0962322A7F7@veritas.com> Subject: Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ketan Nilangekar Cc: Stefan Hajnoczi , Paolo Bonzini , ashish mittal , "Daniel P. Berrange" , Jeff Cody , qemu-devel , Kevin Wolf , Markus Armbruster , Ashish Mittal , Abhijit Dey , Buddhi Madhav , "Venkatesha M.G." , Nitin Jerath , Gaurav Bhandarkar , Abhishek Kane , Ketan Mahajan , Niranjan Pendharkar On Fri, 11/25 08:27, Ketan Nilangekar wrote: > Ketan> We have made a choice to go with QEMU driver approach after serious > evaluation of most if not all standard IO tapping mechanisms including NFS, > NBD and FUSE. None of these has been able to deliver the performance that we > have set ourselves to achieve. Hence the effort to propose this new IO tap > which we believe will provide an alternate to the existing mechanisms and > hopefully benefit the community. Out of curiosity: have you also evaluated the kernel TCMU interface [1] that can do native command exchange very efficiently? It is a relatively new IO tappling mechanism but provides better isolation between QEMU and the backend process with the supervision of kernel. With its "loopback" frontend, theoretically the SG lists can be passed back and forth for local clients. For remote clients, iscsi can be used as the protocol. Fam [1]: https://www.kernel.org/doc/Documentation/target/tcmu-design.txt