From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48207) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WxGlW-0000ud-9D for qemu-devel@nongnu.org; Wed, 18 Jun 2014 10:23:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WxGlO-0008Jn-Kn for qemu-devel@nongnu.org; Wed, 18 Jun 2014 10:23:06 -0400 Received: from lhrrgout.huawei.com ([194.213.3.17]:11914) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WxGlO-0008Iu-Br for qemu-devel@nongnu.org; Wed, 18 Jun 2014 10:22:58 -0400 Message-ID: <53A1A0B4.9030607@huawei.com> Date: Wed, 18 Jun 2014 16:22:44 +0200 From: Claudio Fontana MIME-Version: 1.0 References: <20140610184818.2e490419@nbschild1> <53978375.6090707@6wind.com> <87ppie1v4r.fsf@blackfin.pond.sub.org> <20140612094413.15e56938@nbschild1> <87vbs6qjhj.fsf_-_@blackfin.pond.sub.org> <5399CF09.8030803@6wind.com> <87ppidnqmy.fsf@blackfin.pond.sub.org> <539AC3E0.9090404@6wind.com> <539ACDE6.7020709@redhat.com> <539AFF7C.7090702@6wind.com> <539B064D.2050501@redhat.com> <53A00464.8090609@6wind.com> In-Reply-To: <53A00464.8090609@6wind.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Why I advise against using ivshmem List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 17.06.2014 11:03, David Marchand wrote: > Hello all, > > On 06/17/2014 04:54 AM, Stefan Hajnoczi wrote: >> ivshmem has a performance disadvantage for guest-to-host >> communication. Since the shared memory is exposed as PCI BARs, the >> guest has to memcpy into the shared memory. >> >> vhost-user can access guest memory directly and avoid the copy inside the guest. > > Actually, you can avoid this memory copy using frameworks like DPDK. > > >> Unless someone steps up and maintains ivshmem, I think it should be >> deprecated and dropped from QEMU. > > Then I can maintain ivshmem for QEMU. > If this is ok, I will send a patch for MAINTAINERS file. > > Just a +1 over here for the need of a guest to guest shared memory solution. There are several internal requirements for that, and I saw this discussion just about when starting to build on top of nahanni/ivshmem. In general what I'd like to see is for ivshmem (or any other guest-guest shared memory communication solution) to get consolidated into the QEMU codebase, and not having to pick and choose pieces from different repositories. vhost-user is interesting and welcome, however guest-host communication is not the use case I have over here at the moment. Ciao, Claudio