Thank you for information !

So, you mean the situation is not changed from the reference thread[1] in qemu-devel ML 3 years ago, and the difficulties of ivshmem you mentioned is described in this thread. Am I right?

[1] "[Qemu-devel] Why I advise against using ivshmem"
https://lists.linuxfoundation.org/pipermail/virtualization/2014-June/026767.html

On 2017/05/08 9:09, Daniel P. Berrange wrote:
On Fri, Apr 28, 2017 at 09:38:38AM +0100, sfinu...@redhat.com wrote:
On Fri, 2017-04-28 at 13:23 +0900, TETSURO NAKAMURA wrote:
Hi Nova team,

I'm writing this e-mail because I'd like to have a discussion about
DPDK support at OpenStack Summit in Boston.

We have developed a dpdk-based patch panel named SPP[1], and we'd
like to start working on Openstack (ML2 driver) to develop
"networking-spp".

Especially, we'd like to use DPDK-ivshmem that was used to be used
to create "dpdkr" interface in ovs-dpdk[2].

To the best of my knowledge, IVSHMEM ports are no longer supported in
upstream. The documentation for this feature was recently removed from
OVS [1] stating:

  - The ivshmem library has been removed in DPDK since DPDK 16.11.
  - The instructions/scheme provided will not work with current
    supported and future DPDK versions.
  - The linked patch needed to enable support in QEMU has never
    been upstreamed and does not apply to the last 4 QEMU releases.
  - Userspace vhost has become the defacto OVS-DPDK path to the guest.

Note: I worked on DPDK vSwitch [2] way back when, and there were severe
security implications with sharing a chunk of host memory between
multiple guests (which is how IVSHMEM works). I'm not at all surprised
the feature was killed.

Security is only one of the issues. Upstream QEMU maintainers considered
the ivshmem device to have a seriously flawed design and discourage anyone
from using it. For anything network related QEMU maintainers strongly
recommand using vhost-user.

IIUC, there is some experimental work to create a virtio based replacement
for ivshmem, for non-network related vm-2-vm communications, but that is
not going to be something usable for a while yet. This however just
reinforces the point that ivshmem is considered obsolete / flawed
technology by QEMU maintainers.

Regards,
Daniel


--
Tetsuro Nakamura <nakamura.tets...@lab.ntt.co.jp>
NTT Network Service Systems Laboratories
TEL:0422 59 6914(National)/+81 422 59 6914(International)
3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to