From mboxrd@z Thu Jan 1 00:00:00 1970 From: Markus Armbruster Subject: Re: [PATCH v4 00/17] Wind River Systems AVP PMD vs virtio? - ivshmem is back Date: Thu, 30 Mar 2017 10:55:26 +0200 Message-ID: <87a8839m9t.fsf@dusky.pond.sub.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 To: Stefan Hajnoczi 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) In-Reply-To: <20170317093320.GA11116@stefanha-x1.localdomain> (Stefan Hajnoczi's message of "Fri, 17 Mar 2017 17:33:20 +0800") List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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