[openstack-dev] [nova] Discussions for DPDK support in OpenStack
nakamura.tetsuro at lab.ntt.co.jp
Mon May 8 18:08:46 UTC 2017
Thank you for information !
So, you mean the situation is not changed from the reference thread
in qemu-devel ML 3 years ago, and the difficulties of ivshmem you
mentioned is described in this thread. Am I right?
 "[Qemu-devel] Why I advise against using ivshmem"
On 2017/05/08 9:09, Daniel P. Berrange wrote:
> On Fri, Apr 28, 2017 at 09:38:38AM +0100, sfinucan at 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, and we'd
>>> like to start working on Openstack (ML2 driver) to develop
>>> Especially, we'd like to use DPDK-ivshmem that was used to be used
>>> to create "dpdkr" interface in ovs-dpdk.
>> To the best of my knowledge, IVSHMEM ports are no longer supported in
>> upstream. The documentation for this feature was recently removed from
>> OVS  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  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.
Tetsuro Nakamura <nakamura.tetsuro at 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
More information about the OpenStack-dev