From: Vincent JARDIN <vincent.jardin@6wind.com> To: Markus Armbruster <armbru@redhat.com> Cc: Henning Schild <henning.schild@siemens.com>, qemu-devel@nongnu.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org, David Marchand <david.marchand@6wind.com> Subject: Re: Why I advise against using ivshmem Date: Thu, 12 Jun 2014 18:02:17 +0200 [thread overview] Message-ID: <5399CF09.8030803@6wind.com> (raw) In-Reply-To: <87vbs6qjhj.fsf_-_@blackfin.pond.sub.org> Markus, see inline (I am not on all mailing list, please, keep the cc list). > Sure! The reasons for my dislike range from practical to > philosophical. > > My practical concerns include: > > 1. ivshmem code needs work, but has no maintainer See David's contributions: http://patchwork.ozlabs.org/patch/358750/ > 2. There is no libvirt support One can use qemu without libvivrt. > 3. Out-of-tree server program required for full functionality We have the source code, it provides the documentation to write our own better server program. > 4. Out-of-tree kernel uio driver required No, it is optional. > These concerns are all fixable, but it'll take serious work, and time. > Something like: > > * Find a maintainer for the device model I guess, we can find it into the DPDK.org community. > * Review and fix its code > > * Get the required kernel module upstream which module? uio, it is not required. > * Get all the required parts outside QEMU packaged in major distros, or > absorbed into QEMU Redhat did disable it. why? it is there in QEMU. > In short, create a viable community around ivshmem, either within the > QEMU community, or separately but cooperating. At least, DPDK.org community is a community using it. > On to the more philosophical ones. > > 5. Out-of-tree interface required > > Paraphrasing an old quip: Some people, when confronted with a > problem, think "I know, I'll use shared memory." Now they have two > problems. > > Shared memory is not an interface. It's at best something you can > use to build an interface. > > I'd rather have us offer something with a little bit more structure. > Very fast guest-to-guest networking perhaps. It is not just networking, you have other use cases like HPC, sharing in-memory databases. > > 6. Device models belong into QEMU > > Say you build an actual interface on top of ivshmem. Then ivshmem in > QEMU together with the supporting host code outside QEMU (see 3.) and > the lower layer of the code using it in guests (kernel + user space) > provide something that to me very much looks like a device model. > > Device models belong into QEMU. It's what QEMU does. See my previous statement, it is not just device model. Best regards, Vincent
WARNING: multiple messages have this Message-ID (diff)
From: Vincent JARDIN <vincent.jardin@6wind.com> To: Markus Armbruster <armbru@redhat.com> Cc: Henning Schild <henning.schild@siemens.com>, David Marchand <david.marchand@6wind.com>, qemu-devel@nongnu.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org Subject: Re: [Qemu-devel] Why I advise against using ivshmem Date: Thu, 12 Jun 2014 18:02:17 +0200 [thread overview] Message-ID: <5399CF09.8030803@6wind.com> (raw) In-Reply-To: <87vbs6qjhj.fsf_-_@blackfin.pond.sub.org> Markus, see inline (I am not on all mailing list, please, keep the cc list). > Sure! The reasons for my dislike range from practical to > philosophical. > > My practical concerns include: > > 1. ivshmem code needs work, but has no maintainer See David's contributions: http://patchwork.ozlabs.org/patch/358750/ > 2. There is no libvirt support One can use qemu without libvivrt. > 3. Out-of-tree server program required for full functionality We have the source code, it provides the documentation to write our own better server program. > 4. Out-of-tree kernel uio driver required No, it is optional. > These concerns are all fixable, but it'll take serious work, and time. > Something like: > > * Find a maintainer for the device model I guess, we can find it into the DPDK.org community. > * Review and fix its code > > * Get the required kernel module upstream which module? uio, it is not required. > * Get all the required parts outside QEMU packaged in major distros, or > absorbed into QEMU Redhat did disable it. why? it is there in QEMU. > In short, create a viable community around ivshmem, either within the > QEMU community, or separately but cooperating. At least, DPDK.org community is a community using it. > On to the more philosophical ones. > > 5. Out-of-tree interface required > > Paraphrasing an old quip: Some people, when confronted with a > problem, think "I know, I'll use shared memory." Now they have two > problems. > > Shared memory is not an interface. It's at best something you can > use to build an interface. > > I'd rather have us offer something with a little bit more structure. > Very fast guest-to-guest networking perhaps. It is not just networking, you have other use cases like HPC, sharing in-memory databases. > > 6. Device models belong into QEMU > > Say you build an actual interface on top of ivshmem. Then ivshmem in > QEMU together with the supporting host code outside QEMU (see 3.) and > the lower layer of the code using it in guests (kernel + user space) > provide something that to me very much looks like a device model. > > Device models belong into QEMU. It's what QEMU does. See my previous statement, it is not just device model. Best regards, Vincent
next prev parent reply other threads:[~2014-06-12 16:02 UTC|newest] Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-06-10 16:48 Using virtio for inter-VM communication Henning Schild 2014-06-10 16:48 ` [Qemu-devel] " Henning Schild 2014-06-10 22:15 ` Vincent JARDIN 2014-06-10 22:15 ` Vincent JARDIN 2014-06-10 22:15 ` [Qemu-devel] " Vincent JARDIN 2014-06-12 6:48 ` Markus Armbruster 2014-06-12 6:48 ` Markus Armbruster 2014-06-12 6:48 ` [Qemu-devel] " Markus Armbruster 2014-06-12 7:44 ` Henning Schild 2014-06-12 7:44 ` [Qemu-devel] " Henning Schild 2014-06-12 9:31 ` Vincent JARDIN 2014-06-12 9:31 ` Vincent JARDIN 2014-06-12 9:31 ` [Qemu-devel] " Vincent JARDIN 2014-06-12 12:55 ` Markus Armbruster 2014-06-12 14:40 ` Why I advise against using ivshmem (was: [Qemu-devel] Using virtio for inter-VM communication) Markus Armbruster 2014-06-12 14:40 ` Markus Armbruster 2014-06-12 14:40 ` [Qemu-devel] Why I advise against using ivshmem (was: " Markus Armbruster 2014-06-12 16:02 ` Vincent JARDIN [this message] 2014-06-12 16:02 ` [Qemu-devel] Why I advise against using ivshmem Vincent JARDIN 2014-06-12 16:54 ` Paolo Bonzini 2014-06-12 16:54 ` [Qemu-devel] " Paolo Bonzini 2014-06-13 8:46 ` Markus Armbruster 2014-06-13 9:26 ` Vincent JARDIN 2014-06-13 9:31 ` Jobin Raju George 2014-06-13 9:31 ` Jobin Raju George 2014-06-13 9:31 ` Jobin Raju George 2014-06-13 9:48 ` Olivier MATZ 2014-06-13 9:48 ` Olivier MATZ 2014-06-13 9:48 ` Olivier MATZ 2014-06-13 10:09 ` Paolo Bonzini 2014-06-13 13:41 ` Vincent JARDIN 2014-06-13 13:41 ` Vincent JARDIN 2014-06-13 13:41 ` Vincent JARDIN 2014-06-13 14:10 ` Paolo Bonzini 2014-06-13 14:10 ` Paolo Bonzini 2014-06-14 18:01 ` Vincent JARDIN 2014-06-14 18:01 ` Vincent JARDIN 2014-06-17 2:54 ` Stefan Hajnoczi 2014-06-17 9:03 ` David Marchand 2014-06-17 9:03 ` David Marchand 2014-06-17 9:44 ` Paolo Bonzini 2014-06-18 10:48 ` Stefan Hajnoczi 2014-06-18 10:48 ` Stefan Hajnoczi 2014-06-18 14:57 ` David Marchand 2014-06-18 14:57 ` David Marchand 2014-06-18 14:57 ` David Marchand 2014-06-18 15:10 ` Paolo Bonzini 2014-06-21 9:34 ` Stefan Hajnoczi 2014-06-26 20:02 ` Cam Macdonell 2014-06-26 20:02 ` Cam Macdonell 2014-06-18 15:01 ` Andreas Färber 2014-06-18 15:01 ` Andreas Färber 2014-06-19 8:25 ` David Marchand 2014-06-19 8:25 ` David Marchand 2014-06-19 8:25 ` David Marchand 2014-06-18 15:01 ` Andreas Färber 2014-06-30 11:10 ` Markus Armbruster 2014-06-30 11:10 ` Markus Armbruster 2014-06-30 11:10 ` Markus Armbruster 2014-06-18 10:51 ` Stefan Hajnoczi 2014-06-18 10:51 ` Stefan Hajnoczi 2014-06-18 14:58 ` David Marchand 2014-06-18 14:58 ` David Marchand 2014-06-18 14:58 ` David Marchand 2014-06-18 14:22 ` Claudio Fontana 2014-06-17 9:03 ` David Marchand 2014-06-13 9:29 ` Jobin Raju George 2014-06-13 9:29 ` [Qemu-devel] " Jobin Raju George 2014-06-13 9:29 ` Jobin Raju George 2014-06-12 16:02 ` Vincent JARDIN 2014-06-12 2:27 ` Using virtio for inter-VM communication Rusty Russell 2014-06-12 2:27 ` Rusty Russell 2014-06-12 2:27 ` [Qemu-devel] " Rusty Russell 2014-06-12 5:32 ` Jan Kiszka 2014-06-12 5:32 ` [Qemu-devel] " Jan Kiszka 2014-06-13 0:47 ` Rusty Russell 2014-06-13 0:47 ` [Qemu-devel] " Rusty Russell 2014-06-13 6:23 ` Jan Kiszka 2014-06-13 6:23 ` [Qemu-devel] " Jan Kiszka 2014-06-13 8:45 ` Paolo Bonzini 2014-06-13 8:45 ` [Qemu-devel] " Paolo Bonzini 2014-06-15 6:20 ` Jan Kiszka 2014-06-15 6:20 ` Jan Kiszka 2014-06-15 6:20 ` [Qemu-devel] " Jan Kiszka 2014-06-17 5:24 ` Paolo Bonzini 2014-06-17 5:24 ` [Qemu-devel] " Paolo Bonzini 2014-06-17 5:57 ` Jan Kiszka 2014-06-17 5:57 ` Jan Kiszka 2014-06-17 5:57 ` [Qemu-devel] " Jan Kiszka 2014-06-17 5:24 ` Paolo Bonzini 2014-06-12 5:32 ` Jan Kiszka
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=5399CF09.8030803@6wind.com \ --to=vincent.jardin@6wind.com \ --cc=armbru@redhat.com \ --cc=david.marchand@6wind.com \ --cc=henning.schild@siemens.com \ --cc=kvm@vger.kernel.org \ --cc=qemu-devel@nongnu.org \ --cc=virtualization@lists.linux-foundation.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.