From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id EDF2910BA9 for ; Thu, 30 Mar 2017 10:55:34 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0474780464; Thu, 30 Mar 2017 08:55:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 0474780464 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=armbru@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 0474780464 Received: from blackfin.pond.sub.org (ovpn-116-26.ams2.redhat.com [10.36.116.26]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A0DD81898C; Thu, 30 Mar 2017 08:55:28 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id E88A11138645; Thu, 30 Mar 2017 10:55:26 +0200 (CEST) From: Markus Armbruster To: Stefan Hajnoczi Cc: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , "Wiles\, Keith" , Jason Wang , "Michael S. Tsirkin" , Vincent JARDIN , Stephen Hemminger , "O'Driscoll\, Tim" , "Legacy\, Allain \(Wind River\)" , "Yigit\, Ferruh" , dev@dpdk.org, "Jolliffe\, Ian \(Wind River\)" , Thomas Monjalon References: <1488414008-162839-1-git-send-email-allain.legacy@windriver.com> <9242BBFE-279B-46E3-BC04-62F1FE897824@intel.com> <3140337.WIddM6FeqF@xps13> <20170317093320.GA11116@stefanha-x1.localdomain> Date: Thu, 30 Mar 2017 10:55:26 +0200 In-Reply-To: <20170317093320.GA11116@stefanha-x1.localdomain> (Stefan Hajnoczi's message of "Fri, 17 Mar 2017 17:33:20 +0800") Message-ID: <87a8839m9t.fsf@dusky.pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Thu, 30 Mar 2017 08:55:34 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH v4 00/17] Wind River Systems AVP PMD vs virtio? - ivshmem is back X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 08:55:35 -0000 Stefan Hajnoczi writes: > On Fri, Mar 17, 2017 at 09:48:38AM +0100, Thomas Monjalon wrote: >> We are discussing about IVSHMEM but its support by Qemu is confused. >> This feature is not in the MAINTAINERS file of Qemu. >> Please Qemu maintainers, what is the future of IVSHMEM? Red-headed stepchild? > git-log(1) shows that Marc-Andr=C3=A9 Lureau worked on ivshmem in 2016 but > it's not under very active development at the moment. I have CCed him. Marc-Andr=C3=A9 and I did substantial work to fix ivhmem's worst technical issues, including memory-corrupting race conditions (unlikely ones, but those are arguably the worst). More issues remain. Have a look at docs/specs/ivshmem-spec.txt in the QEMU source tree[1]. It's depressing reading, I'm afraid. In my opinion, merging ivshmem in 2010 was a mistake. Some users have since found it useful (good for them), so we fixed it up for their benefit. Nevertheless, I still can't recommend it. > The vhost-user interface seems to be getting more attention. It's a way > to run virtio devices in separate host processes (e.g. userspace network > switch). > > There was a brief discussion about "ivshmem 2.0" recently but I think > that fizzled out because the use case was narrow: a new and cut-down > device model for real-time use cases. Yes. If you're interested in ivshmem, go read it[2]. At least two good ideas came up: provide for an ID of the next higher protocol level, and generic state signalling. Why do I like these ideas? My main objection to ivshmem's isn't technical flaws, but that it's a bad building block (see [3] item 5). These ideas could make it a less bad building block. Turning ideas into reality is work. Jan Kiszka (who started the discussion) chose not to pursue it, because his requirements don't align with upstream QEMU's very well, so he'd have to do more extra work than he can justify. Bottom line: if you want a better future for ivshmem than the status quo, you need to put in the work and solve some hard problems. [1] Link to my public repository, for convenience: http://repo.or.cz/qemu/armbru.git/blob_plain/HEAD:/docs/specs/ivshmem-spec.= txt [2] https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg02860.html [3] https://lists.gnu.org/archive/html/qemu-devel/2014-06/msg02968.html