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
