Hi Nova team,
It has been quite a long time since the last discussion,
but let me make sure one thing about the thread below.
IIUC, Nova is not welcome ivshmem support because it is no longer
supported by DPDK+QEMU.
But how would you say if it is supported out of DPDK-tree and can be
used from the newest qemu version ?
We are now developing SPP, a DPDK-based vswitch, and thinking about
trying to implement ivshmem support under our SPP code tree if nova (or
at first libvirt community) is acceptable for ivshmem configuration.
Your advice will be very helpful for our decision-making in our project.
Thanks in advance,
Tetsuro Nakamura
On 2017/05/08 22: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
